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.77 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Wed, 14 Aug 2013 12:44:17 -0700
Subject: Re: Storing Version Numbers
Thread-Topic: Storing Version Numbers
Thread-Index: Ac6ZJqvupRKE/3QJTPewNPLWrwYJdA==
Message-ID: <CE312C1E.23D99%fil@adobe.com>
In-Reply-To: 
 <CABiQX1U1NdyMJCMxSW2rDbs-Wu_GQkAhuiXeJMsEVJa5NhiSiA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.6.130613
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Looks good to me!

On 8/14/13 11:49 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:

>Ian's put together a wiki page on how to store version numbers in our
>repos:
>https://wiki.apache.org/cordova/PlatformVersionScripts
>
>I'd like to add info to it for non-platform repos as well, but want to
>draw
>everyone's attention to it on the ML so that we can have easier comments
>about it:
>
>
>=3D All Repositories =3D
>'''Proposal'''
>VERSION files go away. None of the below schemes use them, so they should
>be added only when building Apache release .zips.
>
>=3D Cordova platforms =3D
>
>Cordova platforms should have a simple, reliable method to report their
>version number, for use by automated tools such as CLI and plugman.
>
>The current method for doing this (supported by Android; support coming
>for
>other platforms) is to have a script in the platform package, under
>`bin/templates/cordova/version`, which can be called to report the version
>number.
>
>Previously, this file would, on some platforms, go through some rather
>complicated process to infer the correct version number (such as checking
>the git hash of the included cordova.js file). It will be simpler and
>easier to maintain to have this file simply echo a string constant.
>
>The version number should correspond closely to the git branch. When a
>release branch is made, both the branch and the master branch should be
>updated. The master branch should *always* have a version number ending in
>"-dev", which indicates the version currently being developed. A fresh
>release branch should change the version to an "-rc1" version, and then
>change to the unqualified version number when it is released.
>
>(This constant version number can be updated manually, but *should*
>eventually be updated via coho as release branches are made.)
>
>This should give a rough idea how the version number should advance:
>
>{{{
>         3.3.0-dev
> 3.2.0-dev|
>  |       |
>--A---B---C---D (master)
>       \
>        \--E---F---G---H (3.2.x)
>           |       |   |
>          3.2.0-rc1|  3.2.1-rc1
>                  3.2.0
>}}}
>
> * A: This is on the master branch, after 3.1.x has been branched, as 3.2
>is being developed.
> * B: This is the branch point for 3.2.x
> * C: The first commit after 3.2.x is branched should identify the master
>branch as 3.3 is being developed on master now.
> * E: The first commit on the 3.2.x branch should identify the branch as
>3.2.0-rc1
> * G: At some point, 3.2.0 is released, and should be identified as such
> * H: After 3.2.0 is released, any further development can be called
>3.2.1-rc1
>
>Current support:
>
>||'''Platform'''||'''Support'''||
>||Android       || {*}         ||
>||BB10          || {o}         ||
>||iOS           || {o}         ||
>||OSX           || {o}         ||
>||QT            || {o}         ||
>||Tizen         || {o}         ||
>||WebOS         || {o}         ||
>||Win           || {o}         ||
>||WP7           || {o}         ||
>||WP8           || {o}         ||
>||www           || {o}         ||
>
>=3D Cordova JS =3D
>
>The version of the JS is stamped at the top of the built .js file by
>grunt.
>
>Currently, the version is derived using `git describe` and so is based off
>of the closest git tag in the history. This works well for releases, but
>isn't great for dev builds since there are no tags made on master.
>
>'''Proposal:'''
> 1. Follow platform versioning scheme and store it in a constant within
>Gruntfile.js.
> 1. When in built in the context of a git repo, and not at a tagged
>commit,
>append the git hash.
> 1. When not in a git repo or at a tagged commit, don't try and append a
>hash.
>
>=3D Core Plugins =3D
>
>Current state is that we have master & dev branches. This is because
>plugman pulls from master by default, so it must remain stable.
>
>Once plugman-registry is launched, it should be used instead
>
>'''Proposal:'''
> 1. Stick with dev / master branches
> 1. Releases involve:
>    a. Update plugin.xml's version to "3.1.0"
>    a. Merge dev -> master
>    a. Update plugin.xml's version again to say "3.2.0-dev"
>
>=3D Plugman & CLI =3D
>
>These tools are built as npm modules, and so use package.json & semver
>versioning.