Cordova CLI has a version that is independent of the Cordova releases. (Once we decouple the creating of projects from version locking.)
So I create a project today with Cordova CLI it would use the most recent release. Lets pretend that's 2.7. Cool. A month later I create a project with the CLI and its 2.8. If I run `cordova -v` it will return the version of the CLI tool and maybe a notice about the most recent release if I'm not in a project and the version that project is if I am. I'm not sure how Grunt is handling that part but it would be worth looking into. Basically the CLI is dumb, independently versioned, and the version of Cordova is a project level concern. On Fri, Apr 19, 2013 at 2:33 PM, Michael Brooks <mich...@michaelbrooks.ca> wrote: >> >> 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) >> > >>
