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