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 <[email protected]> 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 <[email protected]> > 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 <[email protected] > >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 <[email protected] > >> >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 > >> > > >> >
