cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: [cordova-cli] npm Version Update
Date Fri, 19 Apr 2013 21:33:28 GMT
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message