Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 46525F5F6 for ; Fri, 19 Apr 2013 22:06:46 +0000 (UTC) Received: (qmail 7758 invoked by uid 500); 19 Apr 2013 22:06:46 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 7719 invoked by uid 500); 19 Apr 2013 22:06:46 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 7711 invoked by uid 99); 19 Apr 2013 22:06:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Apr 2013 22:06:46 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FRT_ADOBE2,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mikeywbrooks@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-wg0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Apr 2013 22:06:42 +0000 Received: by mail-wg0-f44.google.com with SMTP id a12so230346wgh.23 for ; Fri, 19 Apr 2013 15:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=/rdWTjYtJtS9DkW1CXXvQ5SZBdkYsZdMtsf6I9qmyJU=; b=Aan8iZ7UsEvyx3WzMYWnQkFgt2rIz9jl0biD8wzp7Yl/Qxuazel6MaztSfmoGNC9Zj UDfkBsfj10dLDDAOFhKehCXZ5EXKOR1p+9wePi3QndRa6cpD9t2XdRr+FwZGxPto54r3 6Dt8MwSF15EP1jbQVQZBsfpKQ02xQeK2sqa4Bqup0PhdO9RdHVtihwbbTz6v8FGt+Rnf sKvA3sA65F6SWRiGTkMMRkDqpLBl+ouswg4TXxpYLGANjS6bj+FhRls0oMzxpsVoK/2/ xZHti5N25+8ww7gieTOckussiGIW60xcmm3Dg5VEApotUhgsy17+wl6IkVhClXYA9HY7 RqhA== MIME-Version: 1.0 X-Received: by 10.180.94.133 with SMTP id dc5mr6937749wib.1.1366409178541; Fri, 19 Apr 2013 15:06:18 -0700 (PDT) Sender: mikeywbrooks@gmail.com Received: by 10.217.89.71 with HTTP; Fri, 19 Apr 2013 15:06:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 16:06:01 -0600 X-Google-Sender-Auth: 9wupyBwQGg4sU3woPF_YrLi1NOI Message-ID: Subject: Re: [cordova-cli] npm Version Update From: Michael Brooks To: "dev@cordova.apache.org" Content-Type: multipart/alternative; boundary=f46d04462e66b4736d04dabded88 X-Virus-Checked: Checked by ClamAV on apache.org --f46d04462e66b4736d04dabded88 Content-Type: text/plain; charset=ISO-8859-1 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 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 > 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 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 wrote: > >> > Rockin, love it > >> > > >> > On 4/19/13 2:17 PM, "Michael Brooks" > 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) > >> > > >> > --f46d04462e66b4736d04dabded88--