maven 3 version ranges with snapshots

[Paul French <pa...@kirona.com>]

I've added the below to the discussion at...

http://jira.codehaus.org/browse/MNG-3092

...but include here in case anyone else has some ideas.


If you consider semantic versioning http://semver.org/ where by using 
carefully chosen version numbers (enforced by an api analysis tool) and 
version ranges to specify your dependencies between your components then 
version ranges need to support some basic ideas.

I have component A [1.0.0] and component B [1.1.0] and component A 
depends on component B with version range [1.0.0,1.2.0)

A [1.0.0] depends on B [1.0.0,1.2.0)

We start additional development on B so it will initially be B 
[1.1.1-SNAPSHOT] So A will pull this in as it's current dependency i.e. 
B [1.1.1-SNAPSHOT] as a dependency (the current behaviour of maven 3.0.3)

Work continues on B and someone adds a method to an interface which is 
used by A, component B's version is increased to [1.2.0-SNAPSHOT] to 
signal the possible incompatible change since version B [1.1.0]

If you think about it, this snapshot of B could be incompatible to A so 
we need to exclude it in our version range i.e. we modify component A's 
dependency version range on B to exclude the 1.2.0-SNAPSHOT

A [1.0.0] depends on B [1.0.0,1.2.0-SNAPSHOT)

So already I'm not liking this since I have to specify I don't want the 
1.2 SNAPSHOT but I can live with it.

However the dependency pulled in for A will now always be B 
[1.1.1-SNAPSHOT], there will never be a release of B[1.1.1] made by us, 
our baseline is B[1.1.0] and we have not made a new baseline release yet 
for component B but it will at best be [1.2.0] or a later version.

I've concluded but I could be wrong that you need to be able to say 
whether you want to include or exclude SNAPSHOT in your version ranges. 
We develop OSGi bundles. Using the PDE analysis API tooling we compare 
on going development of bundles with a baseline release and update the 
POM/Bundle-Manifest version as appropriate depending on code changes. So 
we require to use version ranges with snapshots included when doing 
continuous integration but do not include SNAPSHOT when doing releases.

I actually would prefer A [1.0.0] depends on B [1.0.0,1.2.0) to actually 
mean...

"A depends on B from 1.0.0 up to but NOT including 1.2.0 or 1.2.0-SNAPSHOT"

 From our point of view, if you do not want 1.2.0 since it will be 
incompatible then you do not want 1.2.0-SNAPSHOT either since it will 
also be incompatible.

To be clear B [1.1.1-SNAPHOT] is valid in the range above by default.

However when building a release we would like to set a property or 
something equivalent (not in the POM, you do not want to have to go 
through all the POMS) and exclude SNAPSHOT in version ranges.

I suspect other people may require other scenarios so I see some form of 
pluggable version range strategy being the answer. You plugin the 
functionality you require. The default behaviour will be what I have 
outlined

My 10 pence


-- 
Paul French
Kirona Solutions Ltd
Tel: 07803 122 058
E-Mail: paul.french@kirona.com
Web: www.kirona.com <http://www.kirona.com>

This email and any attachments are confidential and should only be read 
by those to whom they are addressed. If you are not the intended 
recipient, please contact us on 01625 585511, delete the email 
(including any attachment) from your computer and destroy any copies. 
Any distribution or copying without our prior permission is prohibited. 
Internet communications are not always secure and may be subject to 
delays, non-delivery and unauthorised alterations. Therefore, 
information expressed in this message is not given or endorsed by Kirona 
Solutions Limited ("Kirona") unless otherwise notified by our duly 
authorised representative independent of this message. No warranty is 
given that this email (including any attachment) is virus free. Any 
views or opinions presented are solely those of the author and do not 
necessarily represent those of Kirona.

Registered addresses: Kirona Solutions Limited, Barrington House, Heyes 
Lane, Alderley Edge, Cheshire. SK9 7LA Registered in England and Wales 
No: 04678711

Re: maven 3 version ranges with snapshots

[Ron Wheeler <rw...@artifact-software.com>]

<editorial BS>
Version ranges are pure evil if you want to have repeatable builds and 
want some idea about what you are testing and deploying.
They seem to be used as an alternative to thinking.
<End of editorial BS>

I do have some ideas that I hope will help.

On 13/05/2011 11:42 AM, Paul French wrote:
> I've added the below to the discussion at...
>
> http://jira.codehaus.org/browse/MNG-3092
>
> ...but include here in case anyone else has some ideas.
>
>
> If you consider semantic versioning http://semver.org/ where by using 
> carefully chosen version numbers (enforced by an api analysis tool) 
> and version ranges to specify your dependencies between your 
> components then version ranges need to support some basic ideas.
>
> I have component A [1.0.0] and component B [1.1.0] and component A 
> depends on component B with version range [1.0.0,1.2.0)
>
> A [1.0.0] depends on B [1.0.0,1.2.0)
>
> We start additional development on B so it will initially be B 
> [1.1.1-SNAPSHOT] So A will pull this in as it's current dependency 
> i.e. B [1.1.1-SNAPSHOT] as a dependency (the current behaviour of 
> maven 3.0.3)
>
> Work continues on B and someone adds a method to an interface which is 
> used by A, component B's version is increased to [1.2.0-SNAPSHOT] to 
> signal the possible incompatible change since version B [1.1.0]
>
> If you think about it, this snapshot of B could be incompatible to A 
> so we need to exclude it in our version range i.e. we modify component 
> A's dependency version range on B to exclude the 1.2.0-SNAPSHOT
>
Adding a method to B will not affect A, A can depend on [1.2.0-SNAPSHOT] 
since the methods that it will call are still there.
OTOH, there is no need to change A since it will be perfectly happy with 
B[1.1.0] and any subsequent version of B that is upwards compatible.
You can compile with [1.1.0] and execute with any later version of B.
Is B's scope in A "provided" or "compile"? Compile will include B[1.1.0] 
in A's jar and that may be perfectly alright. Provided will have A using 
whatever version of B that you provide.
>
> A [1.0.0] depends on B [1.0.0,1.2.0-SNAPSHOT)
>
> So already I'm not liking this since I have to specify I don't want 
> the 1.2 SNAPSHOT but I can live with it.
>
So don't. Stick with A's original designed dependency B[1.1.0]. When you 
revisit A and start to use the new method, it will then depend on the 
current production release of B or some SNAPSHOT if you want to use A to 
test B.

> However the dependency pulled in for A will now always be B 
> [1.1.1-SNAPSHOT], there will never be a release of B[1.1.1] made by 
> us, our baseline is B[1.1.0] and we have not made a new baseline 
> release yet for component B but it will at best be [1.2.0] or a later 
> version.
>
Never release anything with a SNAPSHOT dependency if you want to be able 
to maintain it since you have no idea what code is in a SNAPSHOT.
Could be ready to release or in the middle of development.
That is why it is not a Release.
SNAPSHOTS are unstable and do not come with a warranty of usability or 
any fixed specification.
RELEASES are stable and come with a warranty and a known specification. 
That is what you want to run in production.

> I've concluded but I could be wrong that you need to be able to say 
> whether you want to include or exclude SNAPSHOT in your version 
> ranges. We develop OSGi bundles. Using the PDE analysis API tooling we 
> compare on going development of bundles with a baseline release and 
> update the POM/Bundle-Manifest version as appropriate depending on 
> code changes. So we require to use version ranges with snapshots 
> included when doing continuous integration but do not include SNAPSHOT 
> when doing releases.
>
> I actually would prefer A [1.0.0] depends on B [1.0.0,1.2.0) to 
> actually mean...
>
> "A depends on B from 1.0.0 up to but NOT including 1.2.0 or 
> 1.2.0-SNAPSHOT"
>
Just pick 1 version and make sure that you do not break upwards 
compatibility without going back and fixing A.

> From our point of view, if you do not want 1.2.0 since it will be 
> incompatible then you do not want 1.2.0-SNAPSHOT either since it will 
> also be incompatible.
>
> To be clear B [1.1.1-SNAPHOT] is valid in the range above by default.
>
> However when building a release we would like to set a property or 
> something equivalent (not in the POM, you do not want to have to go 
> through all the POMS) and exclude SNAPSHOT in version ranges.
>
> I suspect other people may require other scenarios so I see some form 
> of pluggable version range strategy being the answer. You plugin the 
> functionality you require. The default behaviour will be what I have 
> outlined
>

I hope that no one else is even thinking about this kind of development 
chaos.

Go back to the drawing board and think about what a dependency actually 
means - at compile time, at execution time.

Pay particular attention to how you are going to know what code is 
actually going to be run when the application is in production.

Think about what upwards compatibility actually means.

You are taking advantage of upwards compatibilty all the time with third 
party software. You do not go through all your code and change the 
dependencies on the Java Servlet Engine or log4j everytime your system 
admin upgrades Tomcat. You pray (the system admin probably more than 
you) that the new version of Tomcat will still run your application even 
though the versions have all gone up by big amounts.

You are making a lot of extra work for a negative return.

Free advice.
Do as you wish with it.

Ron
>
> My 10 pence
>
>
> -- 
> Paul French
> Kirona Solutions Ltd
> Tel: 07803 122 058
> E-Mail: paul.french@kirona.com
> Web: www.kirona.com <http://www.kirona.com>
>
> This email and any attachments are confidential and should only be 
> read by those to whom they are addressed. If you are not the intended 
> recipient, please contact us on 01625 585511, delete the email 
> (including any attachment) from your computer and destroy any copies. 
> Any distribution or copying without our prior permission is 
> prohibited. Internet communications are not always secure and may be 
> subject to delays, non-delivery and unauthorised alterations. 
> Therefore, information expressed in this message is not given or 
> endorsed by Kirona Solutions Limited ("Kirona") unless otherwise 
> notified by our duly authorised representative independent of this 
> message. No warranty is given that this email (including any 
> attachment) is virus free. Any views or opinions presented are solely 
> those of the author and do not necessarily represent those of Kirona.
>
> Registered addresses: Kirona Solutions Limited, Barrington House, 
> Heyes Lane, Alderley Edge, Cheshire. SK9 7LA Registered in England and 
> Wales No: 04678711
>