The reason for having the git hash inside cordova-js is because the build output is then taken and placed into other projects, so this makes it possible to go and figure out where things went out of sync. So I think it should remain there. I only really care about having the VERSION around for the individual platforms. In my mind, plugman/cli/plugins can do their own thing. ( especially plugins )
@purplecabbage risingj.com On Wed, Aug 14, 2013 at 1:25 PM, Andrew Grieve <agri...@chromium.org> wrote: > On Wed, Aug 14, 2013 at 4:09 PM, Jesse <purplecabb...@gmail.com> wrote: > > > 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. > > I actually liked this too, but the problem is that it can be out of sync > with other sources of the VERSION. > For plugman/cli/plugins, I think it's still quite discoverable being kept > in the package.json / plugin.xml files. > For cordova-js & platforms, I think we could just as easily keep the > VERSION files and add logic to grunt / create scripts to read the file. > Thoughts? > > > > > Can't we just remove the extra steps with the git hash > > checking? > > > The git hash part is gone for platforms. Are you suggesting removing that > from cordova-js as well? > > > > > > > > > > @purplecabbage > > risingj.com > > > > > > On Wed, Aug 14, 2013 at 12:44 PM, Filip Maj <f...@adobe.com> wrote: > > > > > Looks good to me! > > > > > > On 8/14/13 11:49 AM, "Andrew Grieve" <agri...@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. > > > > > > > > >
