So wait, I had thought thats what you were doing w/ the CLI right now? Or is lazy loading just lazy loading version lock then?
On Fri, Apr 19, 2013 at 3:06 PM, Michael Brooks <mich...@michaelbrooks.ca> wrote: > Totally down with this Brian. However, it doesn't exist today and > realistically it wouldn't exist before 3.0.0. > > My proposed versioning allows us have both today and allows us to > transition to an independent CLI version in the future. > > Today, we can reliably track both the Cordova framework version and begin > tracking a proper CLI version. > > Tomorrow, when the grunt-approach exists, we will already have a proper CLI > version to base off. > > This does bring up the question of ordering though. If the goal is to > decouple the Cordova framework version from the CLI version, then perhaps > the CLI version should come first and Cordova framework should come second: > major.minor.patch+major.minor.patch > > Example: > > 1.0.12+2.7.0 === npm module 1.0.12 and Cordova framework 2.7.0 > > > On Fri, Apr 19, 2013 at 3:47 PM, Brian LeRoux <b...@brian.io> wrote: > >> 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) >> >> > >> >> >>
