On Mon, Aug 12, 2013 at 1:26 PM, Braden Shepherdson <[email protected]>wrote:
> 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. > Do you think without this cadence that platforms will be released too frequently or too infrequently? We've historically used this same cadence for core plugins, so I don't think it's valid to say that we should use it because it worked before. This is an argument for keeping plugins tied to platform releases. > 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. > My understanding of your comment is that you are in support of switching to semver (but your first sentence says otherwise, so I think there is something missing here). - Currently, our platform version numbers map only to dates. You would currently need such a table to figure out which version of android started supporting a binary bridge vs. which version of ios did, etc. - Are you wanting the major/minor to line up for the platforms in terms of reflecting "date released", or reflecting "feature set". I think the hard thing about having the version map to features (e.g. 3.3 means the platform supports varargs, and 3.4 means added support for BSON), is that what if a platform implements BSON before varargs? That said, I think that using semver is still a good idea, but mainly because our plugin system uses semver when specifying dependencies. E.g. <version> tags and <dependency> tags use semver-style checks, so to make these checks work as well as possible, platforms and plugins should aim to follow semver. Another thing we could consider is versioning platforms as a whole via dates (as we do now), but versioning APIs via semver. E.g. every platform would have an Embedder API & a Plugin API. If you are embedding the CordovaWebView, then you'd be interested in the Embedder API. If you are writing a plugin, then you'd be interested in the Plugin API. For things like the behaviour of <preference>s, where it is only the apps that will break when they change (instead of plugins), then we could continue to use our same versioning scheme. > > >> > > >> 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 > > >> > > > >> > > >
