> 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 mu
vanaf Samsung Mobile.
> >
> > Oorspronkelijk bericht ----Van: Uwe Barthel
> > > Datum:31-10-2015
> 05:45 (GMT-08:00)
> > Aan: Maven Developers List >
> > Onderwerp: Re: Maven Release Version Policy
> >
> > great: what is the
;
> Robert
>
> Verzonden vanaf Samsung Mobile.
>
> Oorspronkelijk bericht Van: Uwe Barthel
> Datum:31-10-2015 05:45 (GMT-08:00)
> Aan: Maven Developers List
> Onderwerp: Re: Maven Release Version Policy >
> great: what is the bundle-maven-plugin feat
ung Mobile.
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 wrote:
> if there is a regression, why not just open a Jira issue and f
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 seems there is not any unit
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 wrote:
>
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 segment (which is what the
r
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 g
Barthel
Datum:31-10-2015 05:45 (GMT-08:00)
Aan: Maven Developers List
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] (by Peter Kriens), gets the previous release (!)
a
> 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.
C
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 be
> 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é BOUT
> 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
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 201
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 standard
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 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 to
aware of more classifiers , not just alpha and
> beta.
>
> Robert
>
> Verzonden vanaf Samsung Mobile.
>
> Oorspronkelijk bericht Van: Stephen Connolly
> Datum:30-10-2015 05:16
> (GMT-08:00) Aan: Maven Developers List
> Onderwerp: Maven Release
and identify where we’re not
> strictly adhering. Is it strict semver?
>
>> On Oct 30, 2015, at 5:16 AM, Stephen Connolly
>> wrote:
>>
>> Hey, so...
>>
>> Do we want to accept this implementation I knocked together:
>> https://github.com/CloudBe
Van: Stephen Connolly
Datum:30-10-2015 05:16
(GMT-08:00) Aan: Maven Developers List
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 not
m/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
>
> -
> To unsubscri
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
-St
22 matches
Mail list logo
