I don't like it as squash and rebase can result in the number decreasing again.
If you want strictly increasing numbers with DVCS systems you need either: 1. A central server that hands out build numbers (SPoF anyone?) or 2. A build number based on the system time (e.g. number of seconds since the release tag was cut) Basing the number on the commit distance from the last release tag will not help when people decide to re-order their commits and squash them down to merge them to master. I favour either releasing more often (thereby removing the need to hand -SNAPSHOTs around) or just changing the way you work. To my mind, the benefits that DVCS gives far far outweigh the loss of a "commit number". YMMV and if you really cannot eliminate the need then you may be better suited to a non D VCS. [Others with stronger git-foo than me may have some nicer solutions] -Stephen On 29 April 2013 13:49, Jörg von Frantzius <[email protected]>wrote: > [Crossposting from [email protected], since no reply or other > traffic over there...] > > Hi, > > it's a common requirement to automatically have sequential (i.e. strictly > increasing) version numbers being generated, e.g. based on SVN revision > numbers. Such sequential version numbers can then be used for detection of > updates of software modules, e.g. Netbeans modules or Magnolia modules. > > While the buildnumber-plugin does provide this for Subversion, it doesn't > do so for Git, and there is a corresponding open issue for the > buildnumber-plugin > https://jira.codehaus.org/**browse/MBUILDNUM-93<https://jira.codehaus.org/browse/MBUILDNUM-93>. > There wasn't progress on that issue since a patch was supplied one year > ago, and the problem with that patch seems to be that it replaces the > currently used SHA entirely with the number of commits. > > Git itself does provide a similar feature with git describe ( > https://www.kernel.org/pub/**software/scm/git/docs/git-**describe.html<https://www.kernel.org/pub/software/scm/git/docs/git-describe.html>), > where a buildnumber is composed from commit number followed by short SHA. A > resulting artifact version would look like this: "1.0.4-14-g2414721", where > "1.0.4" is a manually maintained version number, and "14-g2414721" is what > the buildnumber plugin could generate. > > For the same Git branch, resulting version numbers are strictly > increasing and can sensibly be compared and sorted. For different Git > branches, or the same branch evolving differently in separated > repositories, they at least remain distinguishable due to their SHA short > hash. > > I'd be curious whether others also think that this approach would be > suitable for the buildnumber plugin? > > Thanks for any thoughts, > Jörg > > -- > *Dipl. inf. Jörg von Frantzius, System Architect* > > Email mailto:joerg.frantzius@aperto.**de <[email protected]> > Phone +49 30 283921-318 > Fax +49 30 283921-29 > > Aperto AG - In der Pianofabrik > Chausseestraße 5, D-10115 Berlin-Mitte > http://www.aperto.de > http://www.facebook.com/aperto > https://www.xing.com/**companies/apertoag<https://www.xing.com/companies/apertoag> > > HRB 77049, AG Berlin Charlottenburg > Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen > Aufsichtsrat: Bernd Hardes (Vorsitzender) >
