Looks good to me! On 8/14/13 11:49 AM, "Andrew Grieve" <[email protected]> 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.
