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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
