cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: [cordova-cli] npm Version Update
Date Fri, 19 Apr 2013 21:47:38 GMT
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
<michael@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 <fil@adobe.com> wrote:
>> > Rockin, love it
>> >
>> > On 4/19/13 2:17 PM, "Michael Brooks" <michael@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)
>> >
>>

Mime
View raw message