cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: File version numbers in release branches
Date Wed, 03 Apr 2013 00:16:48 GMT
Note that the packager already prepends the git hash in the comments at the
top of the .js files :)


On Tue, Apr 2, 2013 at 4:14 PM, Ian Clelland <iclelland@google.com> wrote:

> I'm all for running `git rev-parse HEAD` when running jake, and putting the
> output somewhere where a dev can easily get to it -- ideally in the
> compiled JS file itself, so there's no doubt about what version is being
> used.
>
> (Dropping the suggestion to use the current date in this case, if it's
> auto-generated)
>
> While we're at it, I would run something like `git status --porcelain |
> grep -v '^\?'` with it, to report whether there were any modified files
> since the commit, and calling the resulting version master-<hash>-modified
> if there are.
>
> Ian
>
>
> On Tue, Apr 2, 2013 at 4:00 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
> > Do you mean to suggest that the current commit hash is inserted when e.g.
> > running jake?  I'de +1 that.
> >
> >
> > On Tue, Apr 2, 2013 at 3:43 PM, Shazron <shazron@gmail.com> wrote:
> >
> > > I like the 'master' version suggestion.
> > >
> > > Implementation details aside - this could be a packaging artifact
> (coho?)
> > > that puts a file with the current branch-hash in it.
> > >
> > >
> > > On Tue, Apr 2, 2013 at 7:46 AM, Ian Clelland <iclelland@chromium.org>
> > > wrote:
> > >
> > > > From cordova-dev, hash 125dca5:
> > > > > Incrememnting the version can be done on the branch, right? This
> > > doesn't
> > > > need to be added back to master.
> > > >
> > > > I think that generally the answer to that commit message should be
> > 'yes',
> > > > we shouldn't be making the claim that the master branch represents
> any
> > > > particular version of cordova.
> > > >
> > > > If the files in the master branch were going to have a version at
> all,
> > it
> > > > would be something like '2.7.0-prerelease', to indicate what the code
> > is
> > > > going to become. After some discussions here, though, I think it is
> > > > probably best just to change the versions of all of the files to
> > 'master'
> > > > -- to have that be the permanent revision number for the master
> branch.
> > > >
> > > > (The only reason I can think to have a version associated with those
> > > files
> > > > is so that people reporting bugs can say "I'm running this version".
> > > > However, if they're running files checked out of the master branch on
> > > > github, then we need to know more specifically what commit they're
> > using.
> > > > It would be far more useful for them to be able to say "It's version
> > > > master-20130402", or to include the commit hash, as "master-5a6b48a",
> > > than
> > > > a general "2.7.0-pre".)
> > > >
> > > > Ian
> > > >
> > >
> >
>

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