[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. 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),
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:[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
HRB 77049, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen
Aufsichtsrat: Bernd Hardes (Vorsitzender)
