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 22:06:01 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message