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] > >
