You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Hervé BOUTEMY <he...@free.fr> on 2015/11/01 09:25:19 UTC
Re: Maven Release Version Policy
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
> <ba...@x-reizend.de> </div><div>Datum:31-10-2015 05:45 (GMT-08:00)
> </div><div>Aan: Maven Developers List <de...@maven.apache.org>
> </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 <he...@free.fr> 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 <he...@free.fr> 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: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Release Version Policy
Posted by Stephen Connolly <st...@gmail.com>.
The whole point of this (to my mind) is when running with -B when you can't
ask the user
On Sunday 1 November 2015, Hervé BOUTEMY <he...@free.fr> wrote:
> 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
> > <barthel@x-reizend.de <javascript:;>> </div><div>Datum:31-10-2015
> 05:45 (GMT-08:00)
> > </div><div>Aan: Maven Developers List <dev@maven.apache.org
> <javascript:;>>
> > </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 <herve.boutemy@free.fr
> <javascript:;>> 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 <herve.boutemy@free.fr
> <javascript:;>> 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: dev-unsubscribe@maven.apache.org
> <javascript:;>
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> > > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
--
Sent from my phone
Re: Maven Release Version Policy
Posted by Uwe Barthel <ba...@x-reizend.de>.
> 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 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?)
This could/should be a part of the version policy implementation.
The release plugin itself only reacts on the result of the version policy.
The package based approach of OSGi (bundle-maven-plugin) will be also interesting in use with Jigsaw (Java 9 modules).
OSGi makes a bit easier with the separation/declaration of public and private packages.
The first idea for POJ (Plain Old Java) could be to configure the more public part as API (like the bundle-maven-plugin also does) or use the whole artifact as API instead. This approach is as strict but clean as possible. But maybe this behaviour is too strict, so it could be a part of a 'strict server' version policy implementation.
mit freundlichen Grüßen
Uwe Barthel
--
barthel@x-reizend.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org