Re: Maven Release Version Policy

2015-11-02 Thread Uwe Barthel
> ok, then what could be done is only a check afterwards that the version > chosen > by the user is consistent with measures on code evolutions So we are back on version policy I think. Only check and stop the release based on the policy. > another idea: perhaps we should have the API propose

Re: Maven Release Version Policy

2015-11-01 Thread Hervé BOUTEMY
; > Robert > > Verzonden vanaf Samsung Mobile. > > Oorspronkelijk bericht Van: Uwe Barthel > <bart...@x-reizend.de> Datum:31-10-2015 05:45 (GMT-08:00) > Aan: Maven Developers List <dev@maven.apache.org> > Onderwerp: Re: Maven Release Version Polic

Re: Maven Release Version Policy

2015-11-01 Thread Stephen Connolly
; > > > Verzonden vanaf Samsung Mobile. > > > > Oorspronkelijk bericht Van: Uwe Barthel > > <bart...@x-reizend.de <javascript:;>> Datum:31-10-2015 > 05:45 (GMT-08:00) > > Aan: Maven Developers List <dev@maven.apache.org > <javas

Re: Maven Release Version Policy

2015-10-31 Thread Hervé BOUTEMY
I don't know what "Cloudbees conventions" are, and how they are superior to everything else = what I understand from the README if we were able to better describe this policy, and compare different policies, that would give a meaning to adding more and providing them by default in the plugin

Re: Maven Release Version Policy

2015-10-31 Thread Hervé BOUTEMY
by that you mean you expect a version policy implementation that runs a bytecode check against previous version (like clirr) then chooses to increase major minor or patch digit? Regards, Hervé Le vendredi 30 octobre 2015 07:33:45 Jason van Zyl a écrit : > I would prefer to move toward

Re: Maven Release Version Policy

2015-10-31 Thread Uwe Barthel
Hi, I’m with Jason to move Maven forward to use (strict) semver as default version strategy. I understand the 'cloudbee' strategy as a more exotic way. But I'm interested in more than one strategy, configurable via plugin or providing by default plugin. mit freundlichen Grüßen Uwe Barthel --

Re: Maven Release Version Policy

2015-10-31 Thread Uwe Barthel
> I'm not sure "strict semver" can be automated: functional change can't be > easily detected if there is no API change The bundle-maven-plugin behaviour is a good base to discuss about I think. mit freundlichen Grüßen Uwe Barthel -- bart...@x-reizend.de > On 31 Oct 2015, at 12:32, Hervé

Re: Maven Release Version Policy

2015-10-31 Thread Uwe Barthel
> great: what is the bundle-maven-plugin feature you're talking about? The ‘baseline’[1] goal. It based on the BND Tool[2] (by Peter Kriens), gets the previous release (!) and check the difference between the byte code. Following semver, any new method (new feature) requires a new minor change.

Re: Maven Release Version Policy

2015-10-31 Thread Hervé BOUTEMY
I'm not sure "strict semver" can be automated: functional change can't be easily detected if there is no API change semver is a great buzzword, but we should try to explain more precisely what can be automated in the plugin to try to follow the buzzword Regards, Hervé Le samedi 31 octobre

Re: Maven Release Version Policy

2015-10-31 Thread Uwe Barthel
> by that you mean you expect a version policy implementation that runs a > bytecode check against previous version (like clirr) then chooses to increase > major minor or patch digit? Why not. But not choose automatically instead of warning or break the release. I’m use the bundle-maven-plugin

Re: Maven Release Version Policy

2015-10-31 Thread Hervé BOUTEMY
great: what is the bundle-maven-plugin feature you're talking about? Regards, Hervé Le samedi 31 octobre 2015 13:18:35 Uwe Barthel a écrit : > > I'm not sure "strict semver" can be automated: functional change can't be > > easily detected if there is no API change > > The bundle-maven-plugin

Re: Maven Release Version Policy

2015-10-31 Thread Hervé BOUTEMY
if there is a regression, why not just open a Jira issue and fix it? I had a look at code, and it seems there is not any unit test against default version policy Regards, Hervé Le samedi 31 octobre 2015 17:41:45 Stephen Connolly a écrit : > On Saturday 31 October 2015, Hervé BOUTEMY

Re: Maven Release Version Policy

2015-10-31 Thread Stephen Connolly
On Saturday 31 October 2015, Hervé BOUTEMY wrote: > I don't know what "Cloudbees conventions" are, and how they are superior to > everything else = what I understand from the README I jusj had to put a readme quickly. It is basically increment the least significant

Re: Maven Release Version Policy

2015-10-31 Thread Robert Scholte
. Oorspronkelijk bericht Van: Stephen Connolly Datum:31-10-2015 12:16 (GMT-08:00) Aan: Maven Developers List Onderwerp: Re: Maven Release Version Policy On Saturday 31 October 2015, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > if there is a regression, why not just op

Re: Maven Release Version Policy

2015-10-31 Thread Stephen Connolly
On Saturday 31 October 2015, Hervé BOUTEMY wrote: > if there is a regression, why not just open a Jira issue and fix it? IIRC when I pointed out the bug 6-9 months ago Robert or somebody said that the new behaviour was by design... > > I had a look at code, and it

Re: Maven Release Version Policy

2015-10-31 Thread Hervé BOUTEMY
ok great! IIUC, it calculates version per package, based on automatic API comparison for release plugin, we need to calculate a version of the whole artifact. And since it's java, not OSGi, then there is no strict separation between API and internal details, I fear such approach won't give a

Re: Maven Release Version Policy

2015-10-31 Thread Robert Scholte
Barthel <bart...@x-reizend.de> Datum:31-10-2015 05:45 (GMT-08:00) Aan: Maven Developers List <dev@maven.apache.org> Onderwerp: Re: Maven Release Version Policy > great: what is the bundle-maven-plugin feature you're talking about? The ‘baseline’[1] goal. It based on the BND Tool[2] (

Maven Release Version Policy

2015-10-30 Thread Stephen Connolly
Hey, so... Do we want to accept this implementation I knocked together: https://github.com/CloudBees-community/cloudbees-maven-release-version-policy If not I'm fine leaving it where it is... but I can get it donated to the ASF if there is interest -Stephen

Re: Maven Release Version Policy

2015-10-30 Thread Jason van Zyl
nocked together: > https://github.com/CloudBees-community/cloudbees-maven-release-version-policy > > If not I'm fine leaving it where it is... but I can get it donated to > the ASF if there is interest > > -Stephen > > ---

Re: Maven Release Version Policy

2015-10-30 Thread Robert Scholte
Van: Stephen Connolly <stephen.alan.conno...@gmail.com> Datum:30-10-2015 05:16 (GMT-08:00) Aan: Maven Developers List <dev@maven.apache.org> Onderwerp: Maven Release Version Policy Hey, so... Do we want to accept this implementation I knocked together: https://github.c

Re: Maven Release Version Policy

2015-10-30 Thread Stephen Connolly
ation I knocked together: >> https://github.com/CloudBees-community/cloudbees-maven-release-version-policy >> >> If not I'm fine leaving it where it is... but I can get it donated to >> the ASF if there is interest >> >> -Stephen >> >>

Re: Maven Release Version Policy

2015-10-30 Thread Stephen Connolly
> (GMT-08:00) Aan: Maven Developers List <dev@maven.apache.org> > Onderwerp: Maven Release Version Policy > Hey, so... > > Do we want to accept this implementation I knocked together: > https://github.com/CloudBees-community/cloudbees-maven-release-version-policy > > If n