cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: Versioning in a 3.0 world
Date Mon, 12 Aug 2013 16:54:51 GMT
2 is about calendar time. 3 is arguing for keeping the platforms in sync
wrt features (and version numbers, at least for the x.y level). We seem to
be in agreement about wanting to keep project-spanning features reasonably
in step. But note that the space for such features is small, if we're only
talking about platforms and tool compatibility.

Braden


On Mon, Aug 12, 2013 at 9:04 AM, Lorin Beer <lorin.beer.dev@gmail.com>wrote:

> 1&2 don't agree, if I understand correctly
> While strict semver is fine for more homogenous projects, I feel the
> versioning system in Cordova must reflect more. For one thing, linking the
> different platforms together in terms of compatibility and supported
> features. Otherwise, things seem far too fragmented; as much as possible
> the major and minor versions should line up for the platforms. No one
> should have to consult a chart to determine feature compatibility between
> platforms. The version number should immediately inform this.
>
> 5. agree, this allows plugins to progress as needed, and independently
>
> On Mon, Aug 12, 2013 at 7:56 AM, Braden Shepherdson <braden@google.com
> >wrote:
>
> > 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
> >
>

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