> 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
;
> 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
; >
> > 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
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
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
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
--
> 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é
> 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.
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
> 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
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
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
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
.
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
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
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
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] (
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
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
>
> ---
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
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
>>
>>
> (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
22 matches
Mail list logo