> > Why not independently version?
Can you elaborate? I don't understand how that work under both the Cordova project and as a consumable npm module. On Fri, Apr 19, 2013 at 3:28 PM, Brian LeRoux <b...@brian.io> wrote: > I don't get it. Why not independently version? > > (I recognize we version lock currently.) > > > On Fri, Apr 19, 2013 at 2:19 PM, Filip Maj <f...@adobe.com> wrote: > > Rockin, love it > > > > On 4/19/13 2:17 PM, "Michael Brooks" <mich...@michaelbrooks.ca> wrote: > > > >>Hey all, > >> > >>I'm planning to change the way we version the Cordova CLI. > >> > >>TL;DR > >>--- > >> > >> 2.7.0+1.0.5 === Cordova 2.7.0 and npm module version 1.0.5 > >> 2.7.1+1.0.12 === Cordova 2.7.1 and npm module version 1.0.12 > >> > >>Current State > >>--- > >> > >>Today, the Cordova CLI uses a major.minor.patch version identifiers to > >>publish to npm. The major and minor identifiers track the Cordova > >>framework > >>version, while the patch identifier is reserved for tracking Cordova > CLI's > >>updates. > >> > >>For example, the current release is 2.6.2. This means it supports Cordova > >>2.6.x and has released two npm version updates since Cordova 2.6.0. > >> > >>The Problem > >>--- > >> > >>The problem is that this approach to versioning does not accurately > >>represent the Cordova framework or the npm module. > >> > >>When the Cordova framework releases a minor patch, such as Cordova 2.6.1, > >>then the npm module cannot represent that update. > >> > >>When the Cordova CLI changes the public module's API, it cannot represent > >>it. This would typically be reserved for a major or minor identifier. > >> > >>The Solution > >>--- > >> > >>In semantic versioning, the version precedance is as follows [1]: > >> > >>1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < > >>1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < > >>1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a > >> > >>We can adopt the following scheme to accurately track both the Cordova > >>framework version and the npm version: > >> > >>major.minor.patch+major.minor.patch > >> > >>The first three m.m.p are to track the Cordova framework. > >>The second three m.m.p track the npm module. > >> > >>I would prefer to flip these, but to keep tagging consistent and > backwards > >>compatible, we must keep the Cordova framework as the first three > >>identifies. > >> > >>Examples: > >> > >> 2.7.0-rc.1+1.0.0 > >> 2.7.0+1.0.5 > >> 2.7.1+1.0.12 > >> > >>The Benefits > >>--- > >> > >>Now Cordova users know exactly what Cordova version is used by the CLI: > >> > >> 2.7.0+1.0.5 === Cordova 2.7.0 > >> 2.7.1+1.0.12 === Cordova 2.7.1 > >> > >>Now npm module users can rely on semantic versioning (normal node > >>practice): > >> > >> 2.7.0+1.0.5 === Cordova CLI is 1.0.5 > >> 2.7.1+1.0.12 === Cordova CLI is 1.0.12 > >> 2.7.1+1.1.0 === Cordova CLI is 1.1.0 - sweet, a nice API was added! > >> 2.7.1+2.0.0 === Cordova CLI is 2.0.0 - oh no! my old APIs are removed! > >> > >>[1] http://semver.org/ @see 12) > > >
