cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <>
Subject Versioning in a 3.0 world
Date Mon, 12 Aug 2013 14:56:10 GMT
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

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

2. No release cadence anymore: things release when they're ready. See #3,

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:

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

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message