s/candence/cadence/
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 >>> > >>>
