Le 22 oct. 2013 19:26, "Matthew Dempsky" <[email protected]> a écrit : > > On Tue, Oct 22, 2013 at 9:10 AM, Stephen Haberman < [email protected]> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
