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.frantz...@aperto.de
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>
<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 <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>
<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.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)
--
*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)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
