To whom it may concern, https://github.com/code54/buildversion-plugin
provides exactly the desired logic.
One caveat exists, which is that pushing tags for past commits will
decrease the revision numer in subsequent builds. But if one sticks to
the maven-release-plugin for tagging, everything should be fine. If more
tags are needed, they should probably got to a dedicated branch.
On 30.04.2013 10:11, Jörg von Frantzius wrote:
Hi Karl-Heinz,
in our specific case we build Magnolia modules
<http://documentation.magnolia-cms.com/reference/module-mechanism.html#Moduleversionhandling>
that have a module descriptor. The module descriptor contains a
version number for that module, which tells the system at runtime
whether an update of the module has occured (the system remembers the
last installed version of each module). If the system detects a
version update, it does run certain update routines for the
encountered version delta of that module. Currently we bake the SVN
revision gleaned from buildnumber-plugin into the module version
number, triggering automatic updates. It is very convenient to have
this happening on each developers' machine, not only on the CI server
(each developer runs his own Magnolia instance): so when a developer
performs an "svn up" the necessary update routines for other
developers' changes will run on his Magnolia instance during hist next
local build and run cycle.
From what I understand of
https://jira.codehaus.org/browse/MBUILDNUM-93 , a similar logic
applies for Netbeans modules.
So it is important here to be able to compare two given buildnumbers,
which is not possible with the Git SHA only. Telling from the command
prompt " [torvalds@g5 git]" in git-describe
<https://www.kernel.org/pub/software/scm/git/docs/git-describe.html>,
it seems that even the inventor of git does see sense in some kind of
compound build numbers that include a commit number and short hash.
Regards,
Jörg
On 29.04.2013 21:50, Karl Heinz Marbaise wrote:
Hi Jörg,
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.
The only requirement I see in that relation ship is that you need a
unique identifier for your packages which is usually mapped by using
a tag (SVN/Git/ ...). This is represented by the version in your
maven artifact. During the usual development you can use the
-SNAPSHOT marker which internally is a timestamp which is independent
of the used VCS (D or not D).
To make things clear in that relationship the build-number is the
revision number of the subversion repository which has nothing to do
with a build-number.
The equivalent for Git is simply the SHA1...nothing else...
The best solution if you really need it use the BUILD_NUMBER
environment from Jenkins/Hudson (other CI system's have similar things).
The most important question which comes into my mind in that
discussion is: Why do you need that "build number" and which purposes
is behind that?
Kind regards
Karl-Heinz Marbaise
--
*Dipl.-Inf. Jörg von Frantzius, Systems 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)
