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 17:26:53 GMT
My counterargument to having a release cadence is that releasing platforms
that haven't changed (which I suspect will happen fairly often in the new
world) is busywork and a waste of effort. I suppose with sufficient
automation in coho this won't be a big problem.

What do we gain from going through the branch-rc-release ceremony every
month, when the plugins are all separate, and the platforms are evolving
slowly?

Braden


On Mon, Aug 12, 2013 at 10:10 AM, Brian LeRoux <b@brian.io> wrote:

> I'd rather we prioritize candence for platforms and continue to pursue
> to continuous delivery for plugins and cli tooling. This has been
> considered!
>
> - The platform cadence has worked well. There's nothing broken there
> to fix. Prioritizing features over delivery is a bad pattern. We moved
> FROM that style of delivery years ago and I see no reason to return to
> it. Yes, some releases have platforms out of sync: and that is why we
> moved to the plugin model.
> - The rapid releases for the cli tools is working. There is nothing
> broken there to fix outside of more committers being able to do it.
> The tools consume the regular releases for which the bulk of the logic
> exists.
> - The rapid releases for plugins makes sense too for the reasons
> stated in my first bullet.
>
>
> On Mon, Aug 12, 2013 at 9:54 AM, Braden Shepherdson <braden@chromium.org>
> wrote:
> > 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