cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Storing Version Numbers
Date Wed, 14 Aug 2013 18:49:09 GMT
Ian's put together a wiki page on how to store version numbers in our repos:

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 =
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

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:

  |       |
--A---B---C---D (master)
        \--E---F---G---H (3.2.x)
           |       |   |
          3.2.0-rc1|  3.2.1-rc1

 * 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
 * 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

Current 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.

 1. Follow platform versioning scheme and store it in a constant within
 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

= 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

 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message