FYI, Gerrit just uses "git describe" and no special "branch/tag dance": https://gerrit.googlesource.com/gerrit/+/stable-2.8/gerrit-war/BUCK & https://gerrit.googlesource.com/gerrit/+/stable-2.8/tools/git.defs (note that I deliberately used a release branch rather than master; also note that the current master says v2.8-rc0-46-gc7ddde3, whereas the v2.8-rc0 tag was made on the stable-2.8 branch, but that branch was later merged back into master; and stable-2.8 said v2.7-1918-gea62148 just before v2.8-rc0 was tagged) An alternative would be to use "--all" and possibly process the output (use 0.0.0 when it says "heads/master", or strip "heads/" when it says "heads/2.6"; but then there's a risk of having two "2.6" referring to different things: refs/heads/2.6 and refs/tags/2.6).
I think we should first ask ourselves: - do we really want to keep the 0.0.0 special version? (would it really hurt if master currently said 2.5.1-250-g4a00f1e?) - and do we really want to have a branch-specific version? (would it really hurt if a newly cut v2.6 branch said 2.5.1-250-g4a00f1e?) If we do want these, then it should be as easy as hard-coding the version in a file somewhere (About.properties or maybe rather the build script), and update this file just after we cut a release branch, so that master would have 0.0.0 and the v2.6 branch would have 2.6. That version could be used as a default value in case "git describe" fails (so that the hard-coded 2.6 version would only be used until we cut a 2.6-rc release; but then we would have to take great care not to make any tag on master, or merge to master any branch containing a tag; and thus is leads us to possibly discuss our "git branching model"), or be updated each time we cut a release (so it'd say 2.6-alpha when cut branch off master, then 2.6-rc when we cut the RC, etc.) The latter is what Maven does BTW (at least with the maven-release-plugin), except the version ends in -SNAPSHOT and is thus changed twice: once just before releasing, to use a non-SNAPSHOT version, and once just after to re-introduce the -SNAPSHOT suffix; the prefix used before and after a release is independent from the non-SNAPSHOT version used for release (how often did I have a 1.0-SNAPSHOT and then release 0.1.0 and moved to 0.2.0-SNAPSHOT; the only issue is if you need to resolve conflicts between the old 1.0-SNAPSHOT and the newer 0.2.0-SNAPSHOT –because Maven would choose the older one, with the higher number–, but then you probably have bigger problems than a version conflict!) On Monday, October 21, 2013 7:37:30 PM UTC+2, Stephen Haberman wrote: > > > > I was thinking about something like that too. I actually kinda like > > it, and it gives an easy monotonic counter for tracking master. > > Agreed. > > > I don't think we're using proper git tags yet. The 'tags' currently > > in the tree for 2.5.1, etc that were imported from SVN are actually > > just regular git commits. > > I think the svn import was smarter than that..."git tag -l" shows tags > for 2.5.0, 2.5.1, 2.5.1-rc1, etc. > > > while intermediary development steps would still be "2.6rc1-42-blah". > > Yep, that makes sense. > > > Hm, something to consider though, I was planning on creating the 2.6 > > branch and then immediately tagging as 2.6rc1. Since tags are > > independent of branches, I think that would actually cause the 2.6rc1 > > tag to be picked up by master too. > > Hm, true...you'd need at least one commit on the 2.6 branch to avoid > it's tags getting picked up by "git describe" on master. I dunno. > > Looking at the DAG for the 2.5.1 branch, it looks like svn had a > "Cutting at r11495 for 2.5.1 RC1" commit at the start of that branch > (granted, svn semantics require that). We could always make a similar > dummy commit. Not great, but not horrible, I think. > > - Stephen > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
