Ian, that sounds great, but as a small nit could we rename alpha to dev? alpha sounds like a release tag, and we've been using dev for upstream work on master. I do like adding the next version information to it.
-Michal On Mon, Jul 8, 2013 at 10:57 PM, Ian Clelland <iclell...@chromium.org>wrote: > On Mon, Jul 8, 2013 at 9:49 PM, Andrew Grieve <agri...@chromium.org> > wrote: > > > Yes! Most of us here have hit that exact problem, but I guess it hadn't > > made it to the ML yet. > > > > It's because Android's version script reports the version by parsing it > out > > of the comment in the cordova.js file. > > > > That's exactly it -- the version script parses the comment and ends up with > '2.7.0rc1', which is passed to semver. That, unfortunately, isn't a valid > semantic version, at least according to semver.org. (2.7.0-rc1 would be, > but that's not how it was tagged) > > The actual version in the JS file is a result of `git describe HEAD > --tags`, and is reporting the hash, and the most-recently tagged version, > looking back through history. In this case, 2.7.0rc1 is the most recent tag > in trunk. (maybe it shouldn't have been; that tag should have been on the > 2.7.x branch?) > > I think we can keep this tagging and versioning sort of sane now -- now > that we have tools for automated release management. > > I'd propose, in addition to Andrew's suggestion of making the version > script echo the hard-coded version (and we make coho write out the correct > version somewhere), that when we cut a new release branch, we have coho > automatically: > > - create a new branch off of master > - name the branch, eg, 3.0.x > - (if appropriate), tag an initial commit like 3.0.0-rc1, on the new > branch > - (new!) tag an initial commit like 3.1.0-alpha on the master branch > > This way, the very next versions of cordova.js that get generated would be > described as '3.0.0-rc1-0-g<somehash>' and '3.1.0-alpha-0-g<somehash>', and > it would be obvious to anyone looking at them what version of cordova they > were intended for. > > With the current setup, cordova.js generated from those two branches would > be described as something like '2.7.0-186-g<hash-1>' and > '2.7.0-186-h<hash-2>', which is not as helpful as it could be -- I think we > can do better, with the tools we have now. > > Ian > > > > > > > > This is completely wrong, since it's not even reporting the version of > the > > Android repo, but rather the version of the cordova-js version. > > > > You can work around it by editing the comment in the .js file, or just > > having the version script echo a newer version. > > > > > > How I think we should fix this problem is by: > > 1. Have the version script hardcode the version within it (or just > convert > > it to a VERSION file) > > 2. Have the create script generate the version script by reading the > > VERSION file. If it says "dev", then use git describe to generate the > > version > > 3. Address CB-3216 so that the version script will be replaced with new > > versions on upgrades. > > > > > > > > On Mon, Jul 8, 2013 at 6:33 PM, Filip Maj <f...@adobe.com> wrote: > > > > > I am going to look into this but you shouldn't have to run the cli, you > > > can run plugman instead but I am not sure if that¹s the answer you are > > > looking for joe ;) > > > > > > On 7/8/13 2:07 PM, "Joe Bowser" <bows...@gmail.com> wrote: > > > > > > >Hey > > > > > > > >I was looking for a quick way to add all the plugins, so I decided to > > > >follow the "WorkingWithThree" wiki to set up a 3.0.0 Cordova project. > > > >I got most of the way through the guide but ran into an error after > > > >running this: > > > > > > > >../cordova-cli/bin/cordova plugin add > > > >../cordova-mobile-spec/dependencies-plugin > > > > > > > >This is the error I got: > > > > > > > >[TypeError: Invalid Version: 2.7.0rc1] > > > > > > > >Any idea why this would happen? Does this have something to do with > > > >how we get the version when we run git describe? It looks like I'm > > > >going to have to install all the plugins manually or write my own > > > >script. > > > > > > > >Side Note: It'd be great if we didn't have to rely on the CLI to do > > > >everything, so that we're not totally SOL if/when we find issues with > > > >the CLI. > > > > > > > > >
