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

[Jörg von Frantzius]

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

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

[Jörg von Frantzius]

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.frantz...@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

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 
 
[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 ope

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

[Curtis Rueden]

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.frantz...@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
>> >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 >
>>  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 

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

[Jörg von Frantzius]

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 Frantziuswrote:


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 
wrote:


   [crosspostingfromu...@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


  .
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

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

[Stephen Connolly]

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 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 >>>
> wrote:
>
   [Crossposting fromu...@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
> >
> 
> 
> >
>
>  .
>>
> 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-**

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

[Jörg von Frantzius]

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 
wrote:

  [Crossposting fromu...@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


.

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*

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

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

[Jörg von Frantzius]

Hi Karl-Heinz,

in our specific case we build Magnolia modules 
 
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 
, 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.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)

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

[Karl Heinz Marbaise]

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 SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de

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

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

[Stephen Connolly]

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 > >wrote:
>>
>>  [Crossposting from u...@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
>>> Aufsicht

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

[Jörg von Frantzius]

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 wrote:


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




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

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

[Curtis Rueden]

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:


  maven-jar-plugin
  2.4
  

  

${maven.build.timestamp}
  

  


Regards,
Curtis


On Mon, Apr 29, 2013 at 8:28 AM, Stephen Connolly <
stephen.alan.conno...@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  >wrote:
>
> > [Crossposting from u...@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 
> > 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

[Stephen Connolly]

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 wrote:

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