Re: [gwt-contrib] being cute with git describe
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.
Re: [gwt-contrib] being cute with git describe
- 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?) FWIW I like 0.0.0 because it strongly differentiates hand-made/master releases vs. official/release branch releases. And it always sorts before release versions, which feels safer to me. Also FWIW, I am not a fan of master's git describe looking like 2.5.1-250- That seems misleading, because if we put the 2.5.1-rc0 tag directly on master's commit B: A - B [2.5.1-rc0] - C - D (master) And the 2.5.1 branch continues off B: A - B [2.5.1-rc0] - E - F [2.5.1] Then describe will name commit C as 2.5.1-rc1-1-C, when really in my mind 2.5.1-rc1 + 1 commit is commit E. On the 2.5.1 branch. There would basically be two 2.5.1-rc1 + 1 commit commits, which, yes, there is still the sha, but that seems confusing IMO. If we do want these, then it should be as easy as hard-coding the version in a file somewhere I see what you're saying, although from a workflow perspective that would mean branching is branch, edit version file, commit which is pretty close to branch, make a dummy commit, tag as 2.5.0-rc1. - 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.
Re: [gwt-contrib] being cute with git describe
On Tue, Oct 22, 2013 at 9:10 AM, Stephen Haberman step...@exigencecorp.comwrote: Also FWIW, I am not a fan of master's git describe looking like 2.5.1-250- That seems misleading, because if we put the 2.5.1-rc0 tag directly on master's commit B: A - B [2.5.1-rc0] - C - D (master) And the 2.5.1 branch continues off B: A - B [2.5.1-rc0] - E - F [2.5.1] Then describe will name commit C as 2.5.1-rc1-1-C, when really in my mind 2.5.1-rc1 + 1 commit is commit E. On the 2.5.1 branch. There would basically be two 2.5.1-rc1 + 1 commit commits, which, yes, there is still the sha, but that seems confusing IMO. This is my instinct too: I'd like to be able to look at a version string and have some intuition about whether it came from a release branch or from master. But that's not a deal breaker for me. If the Git experts working on Gerrit have decided to go with 'ambiguous' descriptions, I'm willing to try out their method; maybe it's not so bad in practice. -- 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.
Re: [gwt-contrib] being cute with git describe
Le 22 oct. 2013 19:26, Matthew Dempsky mdemp...@google.com a écrit : On Tue, Oct 22, 2013 at 9:10 AM, Stephen Haberman step...@exigencecorp.com wrote: Also FWIW, I am not a fan of master's git describe looking like 2.5.1-250- That seems misleading, because if we put the 2.5.1-rc0 tag directly on master's commit B: A - B [2.5.1-rc0] - C - D (master) And the 2.5.1 branch continues off B: A - B [2.5.1-rc0] - E - F [2.5.1] Then describe will name commit C as 2.5.1-rc1-1-C, when really in my mind 2.5.1-rc1 + 1 commit is commit E. On the 2.5.1 branch. There would basically be two 2.5.1-rc1 + 1 commit commits, which, yes, there is still the sha, but that seems confusing IMO. This is my instinct too: I'd like to be able to look at a version string and have some intuition about whether it came from a release branch or from master. But that's not a deal breaker for me. If the Git experts working on Gerrit have decided to go with 'ambiguous' descriptions, I'm willing to try out their method; maybe it's not so bad in practice. I believe it works best if you always merge release branches back to master (which implies that you commit fixes to release branches and merge them back to master, rather than cherry pick from master to releases), or absolutely never. Honestly, I'd just go with our current approach: use 0.0.0 by default with an override at build time, used when you release a new version or possibly for custom builds. At least for now. We'll revisit this when we have moved to the new build tool. -- 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.
Re: [gwt-contrib] being cute with git describe
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.
Re: [gwt-contrib] being cute with git describe
On Sat, Oct 19, 2013 at 1:10 PM, Stephen Haberman step...@exigencecorp.comwrote: So, I was messing with getting Ant to handle this conditional, when I realized if we tag the very first svn commit from 2006 with a dummy 0.0.0 tag: git tag 0.0.0 ab0aa686820319e1 Then on the master branch, git describe --tags shows: 0.0.0-7062-g8a0cf14 I was thinking about something like that too. I actually kinda like it, and it gives an easy monotonic counter for tracking master. (Note I've been using lightweight tags for messing around, but we could use annotated tags...wasn't sure what we'd been using so far.) 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. For 2.6, I'm planning on experimenting with git tags to mark points along the 2.6 release branch. That would make git describe appealing because then the releases would be simply 2.6rc1, 2.6, etc (which would be actual tags too), while intermediary development steps would still be 2.6rc1-42-blah. 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. Not sure how to best cope with that. -- 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.
