This was starting to come up in another thread, but since I think this is a separate issue I wanted to raise the discussion here instead.
We need to decide how we're going to manage releases, versioning and compatibility between plugins, platforms and tools, in the new 3.0 world. (tl;dr at the bottom) There are several related questions here: 1. Do all platforms releases 3.x.0 together? 2. On a monthly cadence or by features or what other criteria? 3. Are plugin releases fully independent of Cordova releases? Are the plugin version numbers fully decoupled from Cordova versions? 4. Are we using semver? For what? If so, that has implications for the deprecation policy and breaking changes. There are several different ways we could go here. I'm going to outline my vision for how we answer these questions, but there are certainly other approaches. My main premise is that each individual component will be much, much more stable than any platform was in the old days. This is especially true of the platforms: they contain little besides bridge and startup code now, and that has been quite stable. Most plugins change infrequently, when bugs are discovered, the specs evolve, and new OS versions are released. I suspect the majority of them will have no changes in a given month. Some are less stable, of course. (FileTransfer, I'm looking at you >:-|) >From this basis, I propose the following plan: 1. Things are versioned independently, and we use semver for everything. That means the plan for 3.x up to Cordova 4.0 is still sound, but the version numbers probably won't line up as in the plan. We'll bump the major versions of every component whenever they have breaking changes, as semver specifies. 2. No release cadence anymore: things release when they're ready. See #3, though. 3. Instead of keeping the platforms synced in time, I propose a stronger condition: we attach meaning to platform versions (but not plugin or tool versions). I mean: Platforms can't release a 3.3.0 until they support whatever new feature it was that caused the bump from 3.2.x (see above re: semver). 4. Meanwhile, the tools are still attached to Cordova versions, as discussed elsewhere, and have versions like 3.3.0-0.12.2. 5. Plugins have unrestricted version numbers; nothing wrong with installing batterystatus 3.1.2 alongside filetransfer 8.4.3, targeting iOS and Android 3.3.x. We have the tools and we specify version constraints, and I suggest that these be how we keep versions in sync, not organizational rules about releases. If, for example, a plugin (whatever its version number) depends on a bridge feature added in Cordova 3.3.0, it can specify that in its <engine> tags. The big advantage in my mind is that this model gives everyone a lot more flexibility. We can update, deprecate and remove things whenever it's time to. We can leave deprecation warnings in for as long as feels appropriate, and then bump the major version and remove them. For our users, they can depend on the old behavior of some plugin, and specify an old version of it, but they can get the latest versions of everything else, including the platform and tools, at least until they hit a new major version. tl;dr: fully independent releases of everything, no schedule, semver for everything. Tools and platforms share version numbers, but in the sense that "you can't be a 3.3.0 platform until you have new feature X"; they don't release at the same time. Braden
