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, 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)
