Hi Stephen,
squashing commits and so decreasing build numbers should only affect
builds from your local repository, as other people's or systems' builds
can be affected only by pushing (and squashing commits after they were
pushed is out of question, right?)
Then how about counting commits only of the "origin" remote repo, which
should not be affected by decreasing commit numbers? This would mean
that build numbers can increase only on fetch from origin, which would
be very similar to how things currently work with buildnumber-plugin and
SVN.
Technically it is of course possible to clone a repository where commits
get squashed after cloning or fetching, but from my understanding that
sounds like an insane setup.
Regards,
Jörg
On 29.04.2013 15:28, Stephen Connolly wrote:
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 <joerg.frantz...@aperto.de>wrote:
[Crossposting from u...@mojo.codehaus.org, 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 <joerg.frantz...@aperto.de>
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)
--
*Dipl. inf. Jörg von Frantzius, System Architect*
Email mailto:joerg.frantz...@aperto.de
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
HRB 77049, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen
Aufsichtsrat: Bernd Hardes (Vorsitzender)
