Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.238 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Fri, 19 Apr 2013 14:19:57 -0700
Subject: Re: [cordova-cli] npm Version Update
Thread-Topic: [cordova-cli] npm Version Update
Thread-Index: Ac49Q6YPdzXocki4RKW6jgyALuVa9A==
Message-ID: <CD970307.1D51F%fil@adobe.com>
In-Reply-To: 
 <CAP7NMPqJ-7hXGmdtdvF-N4g37=Qx2xzE4eBh86-i2BMQXe0bXQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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  =3D=3D=3D Cordova 2.7.0 and npm module version 1.0.5
>  2.7.1+1.0.12 =3D=3D=3D 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  =3D=3D=3D Cordova 2.7.0
>  2.7.1+1.0.12 =3D=3D=3D Cordova 2.7.1
>
>Now npm module users can rely on semantic versioning (normal node
>practice):
>
>  2.7.0+1.0.5  =3D=3D=3D Cordova CLI is 1.0.5
>  2.7.1+1.0.12 =3D=3D=3D Cordova CLI is 1.0.12
>  2.7.1+1.1.0 =3D=3D=3D Cordova CLI is 1.1.0 - sweet, a nice API was added=
!
>  2.7.1+2.0.0 =3D=3D=3D Cordova CLI is 2.0.0 - oh no! my old APIs are remo=
ved!
>
>[1] http://semver.org/ @see 12)