You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jörg von Frantzius <jo...@aperto.de> on 2013/04/29 14:49:19 UTC

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

[Crossposting from user@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. 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: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)

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

Posted by Jörg von Frantzius <jo...@aperto.de>.
Hi Curtis,

concerning the work being done already, there is a patch in 
https://jira.codehaus.org/browse/MBUILDNUM-93 that by default uses the 
commit number instead of the hash.

So the remaining work would be to append the short hash to the commit 
number, and to make this behaviour optional.

Unfortunately, I currently don't have resources to develop an improved 
patch. Hopefully I will if nobody else steps in for some time (weeks or 
months). And before even thinking of doing so, I wanted to be sure the 
patch simply won't get applied like the previous patch :)

Regards,
Jörg

On 30.04.2013 16:17, Curtis Rueden wrote:
> Hi Jörg,
>
>> So I guess an optional parameter for buildnumber-plugin would be fine
>> then?
> Adding an option (or better, populate a second Maven property) to
> buildnumber-maven-plugin makes sense to me. It would be potentially useful,
> not actively harmful, and based on what you said before, the work is
> largely complete. Right?
>
> -Curtis
>
>
> On Tue, Apr 30, 2013 at 3:53 AM, Jörg von Frantzius <
> joerg.frantzius@aperto.de> wrote:
>
>> So I guess an optional parameter for buildnumber-plugin would be fine
>> then? By default people using your described workflow wouldn't see
>> problems, since they'd still use the SHA ony.
>>
>>
>> On 30.04.2013 10:44, Stephen Connolly wrote:
>>
>>> If you push the shared branch back to origin (yes bad practice I know...
>>> so
>>> requires that everyone involved knows that the foo-feature branch will
>>> have
>>> rewrites before merge back to master)
>>>
>>> Ordinarily you would mandate that once a commit is pushed upstream it will
>>> not be rewritten. But if you put in place a policy whereby you allow such
>>> rewrites during the merge back to master phase you can, via policy and
>>> procedures, allow such rewriting.
>>>
>>> I wouldn't be happy with such a usage myself, but I have seen people use
>>> that workflow quite successfully.
>>>
>>>
>>> On 30 April 2013 09:28, Jörg von Frantzius<jo...@aperto.de>
>>>> wrote:
>>>   Hi Stephen,
>>>> this could probably be handled by buildnumber-plugin using the SHA by
>>>> default, and only given some optional parameter it would prefix it with
>>>> the
>>>> commit number?
>>>>
>>>> Out of curiosity, how exactly is the branch shared among the team? Using
>>>> a
>>>> shared filesystem? If everybody simply has a clone of that shared branch,
>>>> my guess is that still nobody should change the history of already pushed
>>>> commits.
>>>>
>>>> Regards,
>>>> Jörg
>>>>
>>>>
>>>> On 29.04.2013 20:56, Stephen Connolly wrote:
>>>>
>>>>   So you don't see a team working on a shared branch and then squashing
>>>>> the
>>>>> 5
>>>>> commits it took to fix FOO-345 and re-ordering commits before pushing to
>>>>> master?
>>>>>
>>>>> All this could take place on origin too... Not saying its recommended
>>>>> workflow, but tools should be defensive otherwise you have no tools when
>>>>> things go wrong
>>>>>
>>>>> On Monday, 29 April 2013, Jörg von Frantzius wrote:
>>>>>
>>>>>    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.frantzius@aperto.de
>>>>>>>
>>>>>>>   wrote:
>>>>>>>>      [Crosspostingfromuser@mojo.**codehaus.org<Cr...@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-pluginhttps://**jira**.codehaus.org/******browse/**<http://codehaus.org/****browse/**>
>>>>>>>> MBUILDNUM-93<http://jira.**codehaus.org/****browse/**MBUILDNUM-93<http://jira.codehaus.org/****browse/MBUILDNUM-93>
>>>>>>>>> <
>>>>>>>> https://jira.**codehaus.org/****browse/**MBUILDNUM-93<http://codehaus.org/**browse/**MBUILDNUM-93>
>>>>>>>> <https://**jira.codehaus.org/**browse/**MBUILDNUM-93<https://jira.codehaus.org/**browse/MBUILDNUM-93>
>>>>>>>> <https://**jira.codehaus.org/****browse/**MBUILDNUM-93<http://jira.codehaus.org/**browse/**MBUILDNUM-93>
>>>>>>>> <http://**jira.codehaus.org/browse/****MBUILDNUM-93<http://jira.codehaus.org/browse/**MBUILDNUM-93>
>>>>>>>> <https://**jira.codehaus.org/**browse/**MBUILDNUM-93<http://jira.codehaus.org/browse/**MBUILDNUM-93>
>>>>>>>> <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-***
>>>>>>>> *****<https://www.kernel.org/pub/******software/scm/git/docs/git-******>
>>>>>>>> <https://www.kernel.org/**pub/****software/scm/git/docs/**git-****<https://www.kernel.org/pub/****software/scm/git/docs/git-****>
>>>>>>>> describe.html<https://www.**ke**rnel.org/pub/**software/scm/**<http://kernel.org/pub/**software/scm/**>
>>>>>>>> git/docs/git-**describe.html<h**ttps://www.kernel.org/pub/****
>>>>>>>> software/scm/git/docs/git-****describe.html<https://www.kernel.org/pub/**software/scm/git/docs/git-**describe.html>
>>>>>>>> <https://www.**kernel.org/pub/****software/scm/**git/docs/git-****<http://kernel.org/pub/**software/scm/**git/docs/git-**>
>>>>>>>> describe.html<http://kernel.**org/pub/software/scm/**git/**
>>>>>>>> docs/git-describe.html<http://kernel.org/pub/software/scm/**git/docs/git-describe.html>
>>>>>>>> <https://www.**kernel.org/pub/**software/scm/**<http://kernel.org/pub/software/scm/**>
>>>>>>>> git/docs/git-describe.html<htt**ps://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*
>>>>>>>>
>>>>>>>> Emailmailto:joerg.frantzius@****aperto.**de   <
>>>>>>>> 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<https://www.xing.com/******companies/apertoag>
>>>>>>>> <https://**www.xing.com/****companies/**apertoag<https://www.xing.com/****companies/apertoag>
>>>>>>>> <https://**www.xing.com/****companies/**apertoag<http://www.xing.com/**companies/**apertoag>
>>>>>>>> <https://**www.xing.com/**companies/**apertoag<https://www.xing.com/**companies/apertoag>
>>>>>>>> <https://**www.xing.com/****companies/**apertoag<http://www.xing.com/**companies/**apertoag>
>>>>>>>> <http://**www.xing.com/companies/****apertoag<http://www.xing.com/companies/**apertoag>
>>>>>>>> <https://**www.xing.com/**companies/**apertoag<http://www.xing.com/companies/**apertoag>
>>>>>>>> <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*
>>>>>> Emailmailto:joerg.frantzius@****aperto.de <http://aperto.de><
>>>>>> Emailmailto%3Ajoerg.**frantzius@aperto.de<Em...@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>
>>>>>> <https://**www.xing.com/**companies/**apertoag<https://www.xing.com/**companies/apertoag>
>>>>>> <https://**www.xing.com/**companies/**apertoag<http://www.xing.com/companies/**apertoag>
>>>>>> <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*
>>>>
>>>> Emailmailto:joerg.frantzius@**aperto.**de  <jo...@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>
>>>> <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)
>>>>
>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail:users-unsubscribe@**maven.**apache.org<users-**
>>>> unsubscribe@maven.apache.org <us...@maven.apache.org>>
>>>> For additional commands, e-mail:users-help@maven.**apache.org<e-...@maven.apache.org>
>>>>
>>>>
>>>>
>> --
>> *Dipl.-Inf. Jörg von Frantzius, System Architect*
>>
>> Email mailto:joerg.frantzius@aperto.**de <jo...@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)
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>


-- 
*Dipl.-Inf. Jörg von Frantzius, System 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)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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

Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Jörg,

> So I guess an optional parameter for buildnumber-plugin would be fine
> then?

Adding an option (or better, populate a second Maven property) to
buildnumber-maven-plugin makes sense to me. It would be potentially useful,
not actively harmful, and based on what you said before, the work is
largely complete. Right?

-Curtis


On Tue, Apr 30, 2013 at 3:53 AM, Jörg von Frantzius <
joerg.frantzius@aperto.de> wrote:

> So I guess an optional parameter for buildnumber-plugin would be fine
> then? By default people using your described workflow wouldn't see
> problems, since they'd still use the SHA ony.
>
>
> On 30.04.2013 10:44, Stephen Connolly wrote:
>
>> If you push the shared branch back to origin (yes bad practice I know...
>> so
>> requires that everyone involved knows that the foo-feature branch will
>> have
>> rewrites before merge back to master)
>>
>> Ordinarily you would mandate that once a commit is pushed upstream it will
>> not be rewritten. But if you put in place a policy whereby you allow such
>> rewrites during the merge back to master phase you can, via policy and
>> procedures, allow such rewriting.
>>
>> I wouldn't be happy with such a usage myself, but I have seen people use
>> that workflow quite successfully.
>>
>>
>> On 30 April 2013 09:28, Jörg von Frantzius<jo...@aperto.de>
>> >wrote:
>>
>>  Hi Stephen,
>>>
>>> this could probably be handled by buildnumber-plugin using the SHA by
>>> default, and only given some optional parameter it would prefix it with
>>> the
>>> commit number?
>>>
>>> Out of curiosity, how exactly is the branch shared among the team? Using
>>> a
>>> shared filesystem? If everybody simply has a clone of that shared branch,
>>> my guess is that still nobody should change the history of already pushed
>>> commits.
>>>
>>> Regards,
>>> Jörg
>>>
>>>
>>> On 29.04.2013 20:56, Stephen Connolly wrote:
>>>
>>>  So you don't see a team working on a shared branch and then squashing
>>>> the
>>>> 5
>>>> commits it took to fix FOO-345 and re-ordering commits before pushing to
>>>> master?
>>>>
>>>> All this could take place on origin too... Not saying its recommended
>>>> workflow, but tools should be defensive otherwise you have no tools when
>>>> things go wrong
>>>>
>>>> On Monday, 29 April 2013, Jörg von Frantzius wrote:
>>>>
>>>>   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.frantzius@aperto.de
>>>>>>
>>>>>>  wrote:
>>>>>>>
>>>>>>>     [Crosspostingfromuser@mojo.**codehaus.org<Cr...@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-pluginhttps://**jira**.codehaus.org/******browse/**<http://codehaus.org/****browse/**>
>>>>>>> MBUILDNUM-93<http://jira.**codehaus.org/****browse/**MBUILDNUM-93<http://jira.codehaus.org/****browse/MBUILDNUM-93>
>>>>>>> ><
>>>>>>> https://jira.**codehaus.org/****browse/**MBUILDNUM-93<http://codehaus.org/**browse/**MBUILDNUM-93>
>>>>>>> <https://**jira.codehaus.org/**browse/**MBUILDNUM-93<https://jira.codehaus.org/**browse/MBUILDNUM-93>
>>>>>>> >
>>>>>>> <https://**jira.codehaus.org/****browse/**MBUILDNUM-93<http://jira.codehaus.org/**browse/**MBUILDNUM-93>
>>>>>>> <http://**jira.codehaus.org/browse/****MBUILDNUM-93<http://jira.codehaus.org/browse/**MBUILDNUM-93>
>>>>>>> >
>>>>>>> <https://**jira.codehaus.org/**browse/**MBUILDNUM-93<http://jira.codehaus.org/browse/**MBUILDNUM-93>
>>>>>>> <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-***
>>>>>>> *****<https://www.kernel.org/pub/******software/scm/git/docs/git-******>
>>>>>>> <https://www.kernel.org/**pub/****software/scm/git/docs/**git-****<https://www.kernel.org/pub/****software/scm/git/docs/git-****>
>>>>>>> >
>>>>>>> describe.html<https://www.**ke**rnel.org/pub/**software/scm/**<http://kernel.org/pub/**software/scm/**>
>>>>>>> git/docs/git-**describe.html<h**ttps://www.kernel.org/pub/****
>>>>>>> software/scm/git/docs/git-****describe.html<https://www.kernel.org/pub/**software/scm/git/docs/git-**describe.html>
>>>>>>> >
>>>>>>> <https://www.**kernel.org/pub/****software/scm/**git/docs/git-****<http://kernel.org/pub/**software/scm/**git/docs/git-**>
>>>>>>> describe.html<http://kernel.**org/pub/software/scm/**git/**
>>>>>>> docs/git-describe.html<http://kernel.org/pub/software/scm/**git/docs/git-describe.html>
>>>>>>> >
>>>>>>> <https://www.**kernel.org/pub/**software/scm/**<http://kernel.org/pub/software/scm/**>
>>>>>>> git/docs/git-describe.html<htt**ps://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*
>>>>>>>
>>>>>>> Emailmailto:joerg.frantzius@****aperto.**de   <
>>>>>>> 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<https://www.xing.com/******companies/apertoag>
>>>>>>> <https://**www.xing.com/****companies/**apertoag<https://www.xing.com/****companies/apertoag>
>>>>>>> >
>>>>>>> <https://**www.xing.com/****companies/**apertoag<http://www.xing.com/**companies/**apertoag>
>>>>>>> <https://**www.xing.com/**companies/**apertoag<https://www.xing.com/**companies/apertoag>
>>>>>>> >
>>>>>>> <https://**www.xing.com/****companies/**apertoag<http://www.xing.com/**companies/**apertoag>
>>>>>>> <http://**www.xing.com/companies/****apertoag<http://www.xing.com/companies/**apertoag>
>>>>>>> >
>>>>>>> <https://**www.xing.com/**companies/**apertoag<http://www.xing.com/companies/**apertoag>
>>>>>>> <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*
>>>>>
>>>>> Emailmailto:joerg.frantzius@****aperto.de <http://aperto.de><
>>>>> Emailmailto%3Ajoerg.**frantzius@aperto.de<Em...@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>
>>>>> <https://**www.xing.com/**companies/**apertoag<https://www.xing.com/**companies/apertoag>
>>>>> >
>>>>> <https://**www.xing.com/**companies/**apertoag<http://www.xing.com/companies/**apertoag>
>>>>> <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*
>>>
>>> Emailmailto:joerg.frantzius@**aperto.**de  <jo...@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>
>>> <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)
>>>
>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail:users-unsubscribe@**maven.**apache.org<users-**
>>> unsubscribe@maven.apache.org <us...@maven.apache.org>>
>>> For additional commands, e-mail:users-help@maven.**apache.org<e-...@maven.apache.org>
>>>
>>>
>>>
>
> --
> *Dipl.-Inf. Jörg von Frantzius, System Architect*
>
> Email mailto:joerg.frantzius@aperto.**de <jo...@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)
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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

Posted by Jörg von Frantzius <jo...@aperto.de>.
So I guess an optional parameter for buildnumber-plugin would be fine 
then? By default people using your described workflow wouldn't see 
problems, since they'd still use the SHA ony.

On 30.04.2013 10:44, Stephen Connolly wrote:
> If you push the shared branch back to origin (yes bad practice I know... so
> requires that everyone involved knows that the foo-feature branch will have
> rewrites before merge back to master)
>
> Ordinarily you would mandate that once a commit is pushed upstream it will
> not be rewritten. But if you put in place a policy whereby you allow such
> rewrites during the merge back to master phase you can, via policy and
> procedures, allow such rewriting.
>
> I wouldn't be happy with such a usage myself, but I have seen people use
> that workflow quite successfully.
>
>
> On 30 April 2013 09:28, Jörg von Frantzius<jo...@aperto.de>wrote:
>
>> Hi Stephen,
>>
>> this could probably be handled by buildnumber-plugin using the SHA by
>> default, and only given some optional parameter it would prefix it with the
>> commit number?
>>
>> Out of curiosity, how exactly is the branch shared among the team? Using a
>> shared filesystem? If everybody simply has a clone of that shared branch,
>> my guess is that still nobody should change the history of already pushed
>> commits.
>>
>> Regards,
>> Jörg
>>
>>
>> On 29.04.2013 20:56, Stephen Connolly wrote:
>>
>>> So you don't see a team working on a shared branch and then squashing the
>>> 5
>>> commits it took to fix FOO-345 and re-ordering commits before pushing to
>>> master?
>>>
>>> All this could take place on origin too... Not saying its recommended
>>> workflow, but tools should be defensive otherwise you have no tools when
>>> things go wrong
>>>
>>> On Monday, 29 April 2013, Jörg von Frantzius wrote:
>>>
>>>   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.frantzius@aperto.de
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>    [Crosspostingfromuser@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-pluginhttps://jira**.codehaus.org/****browse/**
>>>>>> MBUILDNUM-93<http://jira.codehaus.org/****browse/MBUILDNUM-93><
>>>>>> https://jira.**codehaus.org/**browse/**MBUILDNUM-93<https://jira.codehaus.org/**browse/MBUILDNUM-93>
>>>>>> <https://**jira.codehaus.org/**browse/**MBUILDNUM-93<http://jira.codehaus.org/browse/**MBUILDNUM-93>
>>>>>> <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-******<https://www.kernel.org/pub/****software/scm/git/docs/git-****>
>>>>>> describe.html<https://www.**kernel.org/pub/**software/scm/**
>>>>>> git/docs/git-**describe.html<https://www.kernel.org/pub/**software/scm/git/docs/git-**describe.html>
>>>>>> <https://www.**kernel.org/pub/**software/scm/**git/docs/git-**
>>>>>> describe.html<http://kernel.org/pub/software/scm/**git/docs/git-describe.html>
>>>>>> <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*
>>>>>>
>>>>>> Emailmailto:joerg.frantzius@**aperto.**de   <jo...@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>
>>>>>> <https://**www.xing.com/**companies/**apertoag<https://www.xing.com/**companies/apertoag>
>>>>>> <https://**www.xing.com/**companies/**apertoag<http://www.xing.com/companies/**apertoag>
>>>>>> <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*
>>>>
>>>> Emailmailto:joerg.frantzius@**aperto.de<Em...@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>
>>>> <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*
>>
>> Emailmailto:joerg.frantzius@aperto.**de  <jo...@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)
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail:users-help@maven.apache.org
>>
>>


-- 
*Dipl.-Inf. Jörg von Frantzius, System 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)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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

Posted by Stephen Connolly <st...@gmail.com>.
If you push the shared branch back to origin (yes bad practice I know... so
requires that everyone involved knows that the foo-feature branch will have
rewrites before merge back to master)

Ordinarily you would mandate that once a commit is pushed upstream it will
not be rewritten. But if you put in place a policy whereby you allow such
rewrites during the merge back to master phase you can, via policy and
procedures, allow such rewriting.

I wouldn't be happy with such a usage myself, but I have seen people use
that workflow quite successfully.


On 30 April 2013 09:28, Jörg von Frantzius <jo...@aperto.de>wrote:

> Hi Stephen,
>
> this could probably be handled by buildnumber-plugin using the SHA by
> default, and only given some optional parameter it would prefix it with the
> commit number?
>
> Out of curiosity, how exactly is the branch shared among the team? Using a
> shared filesystem? If everybody simply has a clone of that shared branch,
> my guess is that still nobody should change the history of already pushed
> commits.
>
> Regards,
> Jörg
>
>
> On 29.04.2013 20:56, Stephen Connolly wrote:
>
>> So you don't see a team working on a shared branch and then squashing the
>> 5
>> commits it took to fix FOO-345 and re-ordering commits before pushing to
>> master?
>>
>> All this could take place on origin too... Not saying its recommended
>> workflow, but tools should be defensive otherwise you have no tools when
>> things go wrong
>>
>> On Monday, 29 April 2013, Jörg von Frantzius wrote:
>>
>>  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.frantzius@aperto.de
>>>>
>>>>> wrote:
>>>>>
>>>>   [Crossposting fromuser@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-pluginhttps://jira**.codehaus.org/****browse/**
>>>>> MBUILDNUM-93 <http://jira.codehaus.org/****browse/MBUILDNUM-93><
>>>>> https://jira.**codehaus.org/**browse/**MBUILDNUM-93<https://jira.codehaus.org/**browse/MBUILDNUM-93>
>>>>> >
>>>>> <https://**jira.codehaus.org/**browse/**MBUILDNUM-93<http://jira.codehaus.org/browse/**MBUILDNUM-93>
>>>>> <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-******<https://www.kernel.org/pub/****software/scm/git/docs/git-****>
>>>>> describe.html<https://www.**kernel.org/pub/**software/scm/**
>>>>> git/docs/git-**describe.html<https://www.kernel.org/pub/**software/scm/git/docs/git-**describe.html>
>>>>> >
>>>>> <https://www.**kernel.org/pub/**software/scm/**git/docs/git-**
>>>>> describe.html<http://kernel.org/pub/software/scm/**git/docs/git-describe.html>
>>>>> <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*
>>>>>
>>>>> Emailmailto:joerg.frantzius@**aperto.**de  <jo...@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>
>>>>> <https://**www.xing.com/**companies/**apertoag<https://www.xing.com/**companies/apertoag>
>>>>> >
>>>>> <https://**www.xing.com/**companies/**apertoag<http://www.xing.com/companies/**apertoag>
>>>>> <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*
>>>
>>> Emailmailto:joerg.frantzius@**aperto.de<Em...@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>
>>> <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.frantzius@aperto.**de <jo...@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)
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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

Posted by Jörg von Frantzius <jo...@aperto.de>.
Hi Stephen,

this could probably be handled by buildnumber-plugin using the SHA by 
default, and only given some optional parameter it would prefix it with 
the commit number?

Out of curiosity, how exactly is the branch shared among the team? Using 
a shared filesystem? If everybody simply has a clone of that shared 
branch, my guess is that still nobody should change the history of 
already pushed commits.

Regards,
Jörg

On 29.04.2013 20:56, Stephen Connolly wrote:
> So you don't see a team working on a shared branch and then squashing the 5
> commits it took to fix FOO-345 and re-ordering commits before pushing to
> master?
>
> All this could take place on origin too... Not saying its recommended
> workflow, but tools should be defensive otherwise you have no tools when
> things go wrong
>
> On Monday, 29 April 2013, Jörg von Frantzius wrote:
>
>> 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.frantzius@aperto.de
>>>> wrote:
>>>   [Crossposting fromuser@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-pluginhttps://jira.codehaus.org/****browse/MBUILDNUM-93<https://jira.codehaus.org/**browse/MBUILDNUM-93>
>>>> <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>
>>>> <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*
>>>>
>>>> Emailmailto:joerg.frantzius@aperto.**de  <jo...@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>
>>>> <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*
>>
>> Emailmailto: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<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.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)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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

Posted by Stephen Connolly <st...@gmail.com>.
So you don't see a team working on a shared branch and then squashing the 5
commits it took to fix FOO-345 and re-ordering commits before pushing to
master?

All this could take place on origin too... Not saying its recommended
workflow, but tools should be defensive otherwise you have no tools when
things go wrong

On Monday, 29 April 2013, Jörg von Frantzius wrote:

> 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.frantzius@aperto.de
>> >wrote:
>>
>>  [Crossposting from user@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>
>>> <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>
>>> <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 <jo...@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>
>>> <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.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<https://www.xing.com/companies/apertoag>
>
> HRB 77049, AG Berlin Charlottenburg
> Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen
> Aufsichtsrat: Bernd Hardes (Vorsitzender)
>


-- 
Sent from my phone

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

Posted by Jörg von Frantzius <jo...@aperto.de>.
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 <jo...@aperto.de>wrote:
>
>> [Crossposting from user@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 <jo...@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.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)

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

Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Jörg,

I agree with Stephen.

> 1. A central server that hands out build numbers (SPoF anyone?)

I like Jenkins for this: just forward the value of the BUILD_NUMBER
environment variable to your Maven build.

> 2. A build number based on the system time (e.g. number of seconds
> since the release tag was cut)

That works too, and can be easily included in the JAR manifest:

        <plugin>
          <artifactId>maven-jar-plugin</artifactId>
          <version>2.4</version>
          <configuration>
            <archive>
              <manifestEntries>

<Implementation-Date>${maven.build.timestamp}</Implementation-Date>
              </manifestEntries>
            </archive>
          </configuration>
        </plugin>

Regards,
Curtis


On Mon, Apr 29, 2013 at 8:28 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> 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.frantzius@aperto.de
> >wrote:
>
> > [Crossposting from user@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 <jo...@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)
> >
>

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

Posted by Stephen Connolly <st...@gmail.com>.
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 <jo...@aperto.de>wrote:

> [Crossposting from user@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 <jo...@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)
>

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

Posted by 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)

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

Posted by Jörg von Frantzius <jo...@aperto.de>.
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: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)

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

Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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
-- 
SoftwareEntwicklung Beratung Schulung    Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise        ICQ#: 135949029
Hauptstrasse 177                         USt.IdNr: DE191347579
52146 Würselen                           http://www.soebes.de

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org