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
another idea: perhaps we should have the API propose multiple versions instead of only one. This would help people understand that the API is only about guessing a natural "next" version, but there are multiple good answers and the right one is really depending on what the user wants to do at current time (going to next major version or minor version?) The current API makes people think the coded algorithm can be always "right" Regards, Hervé Le samedi 31 octobre 2015 07:18:25 Robert Scholte a écrit : > IIRC Simone did an attempt but stopped when he discovered that the > maven-release-plugin wants to know the version up front where as semver > requires compilation first causing a chicken / egg problem. > > Robert > > Verzonden vanaf Samsung Mobile. > > <div>-------- Oorspronkelijk bericht --------</div><div>Van: Uwe Barthel > <[email protected]> </div><div>Datum:31-10-2015 05:45 (GMT-08:00) > </div><div>Aan: Maven Developers List <[email protected]> > </div><div>Onderwerp: Re: Maven Release Version Policy </div><div> </div>> > 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. Changes in Interfaces or > method signatures are incompatible and forces a major change. It is a bit > more complex but not rocket science. :-) > > [1] > http://svn.apache.org/repos/asf/felix/releases/maven-bundle-plugin-3.0.0/do > c/site/baseline-mojo.html [2] http://www.aqute.biz/Bnd/Versioning > > mit freundlichen Grüßen > Uwe Barthel > > > On 31 Oct 2015, at 13:26, Hervé BOUTEMY <[email protected]> wrote: > > > > 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 behaviour is a good base to discuss about I > >> think. > >> > >> mit freundlichen Grüßen > >> Uwe Barthel > >> > >>> On 31 Oct 2015, at 12:32, Hervé BOUTEMY <[email protected]> wrote: > >>> > >>> 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 2015 12:14:09 Uwe Barthel a écrit : > >>>> 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 > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
