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 <
[email protected]> 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<joerg.frantzius@**aperto.de<[email protected]>
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 <[email protected]
wrote:
[Crosspostingfromuser@mojo.**codehaus.org<[email protected]>,
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 <
[email protected]>
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.**[email protected]<emailmailto%[email protected]>
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 <[email protected]>
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-**
[email protected] <[email protected]>>
For additional commands,
e-mail:users-help@maven.**apache.org<e-mail%[email protected]>
--
*Dipl.-Inf. Jörg von Frantzius, System Architect*
Email mailto:joerg.frantzius@aperto.**de <[email protected]>
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<[email protected]>
For additional commands, e-mail: [email protected]
--
*Dipl.-Inf. Jörg von Frantzius, System Architect*
Email mailto:[email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
