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 purplecabbage@gmail.com
 designates 209.85.212.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CE312C1E.23D99%fil@adobe.com>
References: 
 <CABiQX1U1NdyMJCMxSW2rDbs-Wu_GQkAhuiXeJMsEVJa5NhiSiA@mail.gmail.com>
	<CE312C1E.23D99%fil@adobe.com>
Date: Wed, 14 Aug 2013 13:09:47 -0700
Message-ID: 
 <CAKP6k2uVnJ6v1=S1trW=YDjY37+uCB8c+P7O3HHXuG-N=bYjdQ@mail.gmail.com>
Subject: Re: Storing Version Numbers
From: Jesse <purplecabbage@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b3a86f675df9204e3edf0eb

--047d7b3a86f675df9204e3edf0eb
Content-Type: text/plain; charset=ISO-8859-1

windows8 + wp7 and wp8 all have the version script as well, but it simply
echos the content of the ../VERSION file
Currently the dev branch has a VERSION of 0.0.0 because I needed it to be a
valid version number format for other things.

I like the transparency of simply having a VERSION file at the root of any
cordova project.  Can't we just remove the extra steps with the git hash
checking?


@purplecabbage
risingj.com


On Wed, Aug 14, 2013 at 12:44 PM, Filip Maj <fil@adobe.com> wrote:

> 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:
> >
> >
> >= All Repositories =
> >'''Proposal'''
> >VERSION files go away. None of the below schemes use them, so they should
> >be added only when building Apache release .zips.
> >
> >= Cordova platforms =
> >
> >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}         ||
> >
> >= Cordova JS =
> >
> >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.
> >
> >= Core Plugins =
> >
> >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"
> >
> >= Plugman & CLI =
> >
> >These tools are built as npm modules, and so use package.json & semver
> >versioning.
>
>

--047d7b3a86f675df9204e3edf0eb--