Migration to v2

[AndrewBelt]

Rack v2 is roughly a year away, but the plan is to be mostly API-compatible with v1 plugins, or at least 90% of them.

However, the version strings of plugins will need to be bumped to 2.x. I propose that for open-source plugins that have not been migrated by a week before the Rack v2 release, we try to compile them as-is, and if they build, I can manually change their version string to 2.m.0 or something until the plugin developer submits an update.

[AndrewBelt]

I'm bikeshedding on a format to use for automatically migrated version numbers. Should I convert v1.Y.Z to v2.auto.Y.Z for everything, or something? @cschol

[cschol]

I was thinking about it and am wondering why the version needs to be different at all. That version would be 2.0.0 for release. If they developer submits an update she would be required to update the version number to something greater. The integration process could detect that and require a version bump before integration.

How would you change the version number? In the .json in the manifest directory?

[AndrewBelt]

A few days before Rack v2 is released and about 4 weeks after Rack v2's source is released, I'll do these "auto-builds" for plugins that haven't yet been migrated. I'll write a script to change the plugin.json version in each repo and do a build. If it fails, it'll be skipped. The issue with calling it v2.0.0 is that the user won't know what v1 version it was built from. The developer might later want to release their own version called v2.0.0, which would conflict.

It just occurred to me that it also might be the case that when Rack v3 is released, a v1 plugin still hasn't been migrated, so I think the "auto-build" version should include the major version number as well. So I propose changing v1.2.3 to v2.migrated.1.2.3.

[cschol]

That version is clear and makes sense. Update-wise, as far as Rack is concerned, 2.0.0 is greater than 2.migrated.1.2.3 and would update correctly?

[AndrewBelt]

Rack doesn't define a total order on version strings. If Rack sees a nonequal version string on the Library, it will download and install that version.

[cschol]

A couple of thoughts & questions on v2 release preparation from an open source plugin perspective:

• I will create a new v2 project board that will track integrations for v2 plugins (initial migration and later integration).
• Question: Assumption is there will be a v2 branch in the library repo for managing the v2 branch. How are we managing the migration on a source control level? For example: remove all submodules, empty repos directory, and then re-adding submodules for all integrated v2 plugins? Or can this be handled with manifests?
• People are already making additional v2 changes to their modules. Therefore, we need to plan to run through a full review/integration for (worst case) all 179 plugins. A lot of it is automated by now (except code inspection and "crash test", i.e. load in module browser).
• As soon as we have a working tool chain (with next SDK), I will start doing test build of some already available v2 plugins and perhaps we can have forum developers test those builds. This will help validate the tool chain with the new compilers across all platforms.