> 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 (baseline) for similar behaviour at build time.
But it is strong bundled on OSGi version philosophy.

mit freundlichen Grüßen
Uwe Barthel
-- 
[email protected]


> On 31 Oct 2015, at 12:28, Hervé BOUTEMY <[email protected]> wrote:
> 
> 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 semver and identify where we’re not
>> strictly adhering. Is it strict semver?
>>> On Oct 30, 2015, at 5:16 AM, Stephen Connolly
>>> <[email protected]> wrote:
>>> 
>>> Hey, so...
>>> 
>>> Do we want to accept this implementation I knocked together:
>>> https://github.com/CloudBees-community/cloudbees-maven-release-version-pol
>>> icy
>>> 
>>> 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 unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>> 
>> the course of true love never did run smooth ...
>> 
>> -- Shakespeare
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> 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]

Reply via email to