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 Sat, 20 Apr 2013 17:32:50 GMT
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
<michael@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
>> <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