cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <>
Subject Re: Errors following "WorkingWithThree" wiki
Date Tue, 09 Jul 2013 02:57:33 GMT
On Mon, Jul 8, 2013 at 9:49 PM, Andrew Grieve <> 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 (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

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


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

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