Re: buildnumber-plugin: sequential (increasing) build numbers with Git

[Jörg von Frantzius <jo...@aperto.de>]

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.frantzius@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)