Quantcast

Version ranges not working

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Version ranges not working

Jesse Long
Dear Maven Community,

I am writing to beg you to fix the problems with the version ranges in
Maven 3.0.5, specifically regarding the defining compatible version ranges.

I am using Maven 3.0.4. I have a simple project that depends on
org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
[1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define
the version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api
version 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
slf4j-api version 1.6.0-alpha2 is linked in.

Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
released it would probably break again.

This is all too counter-intuitive. The current version of SLF4J is
1.7.1. If my project was to be built against it, knowing that there is a
likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
does not adhere to SemVer), I would like to define my version range for
slf4j-api as [1.7.0,1.8.0). I have no way of knowing before the time
what type of -RC0, -alpha2 qualified releases will be made for 1.8.0, so
I can only exclude 1.8.0.

However, when 1.8.0-alpha2 is released with incompatible changes, my
build will immediately be broken.

I could depend on version 1.5.11 directly, without using a version
range, but Maven considers this a soft version dependency and will
ignore it as needed.

It is apparent that there is no reliable way to define a compatibility
range in Maven. I feel that this should be a major concern to all Maven
users and developers.

It would be a shame for all the effort made by the Maven community to
make software builds stable and reproducible to be undermined by
consistent, predictable breakage described above.

I have read in mailing list archives that the suggested way of excluding
all 1.8.0 pre-release version is to define an exclusive upper bound as
1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with
1.6.0-RC0, this does not work. Also, it makes no sense at all for a user
to wish to include 1.8.0-SNAPSHOT and not 1.8.0.

My proposal is that the qualifier is ignored when comparing a version to
the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
considered to fall outside of the version range. Importantly, it should
only be for the special case of comparing to the version number in an
exclusive upper bound.

If the powers that be see fit, an exception could be made for service
pack qualifiers, which according to one web page on Maven version
ordering I read, should be sorted after the release, although I would
prefer to see Maven more closely aligned to SemVer, where all qualified
version numbers are considered pre-release versions. I consider 1.7.2 a
better version number than 1.7.1-sp1.

Ultimately, I would like to be able to make things as easy as possible
for users depending on a library that adheres to SemVer, to define a
compatibility range like: [1.4.0,2.0.0). I see no reason why it should
not be as easy as that.

Please consider fixing this soon.

I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
signup link on this page displays an error:
http://maven.apache.org/users/getting-help.html

Jira issue MNG-3092, reported over 5 years ago, is related to this
issue, but the initial report is for a similar issue, not this issue.
The issue I describe above is reported and discussed in the comments for
MNG-3092 though.

Thanks,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

stephenconnolly
On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:

> Dear Maven Community,
>
> I am writing to beg you to fix the problems with the version ranges in
> Maven 3.0.5, specifically regarding the defining compatible version ranges.
>
> I am using Maven 3.0.4. I have a simple project that depends on
> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define the
> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
> version 1.6.0-alpha2 is linked in.
>
> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
> released it would probably break again.
>
> This is all too counter-intuitive. The current version of SLF4J is 1.7.1.
> If my project was to be built against it, knowing that there is a
> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J does
> not adhere to SemVer), I would like to define my version range for
> slf4j-api as [1.7.0,1.8.0). I


I think you do [1.7.0,1.8.0-!)

but that might just include 1.8.0-SNAPSHOT


> have no way of knowing before the time what type of -RC0, -alpha2
> qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.
>
> However, when 1.8.0-alpha2 is released with incompatible changes, my build
> will immediately be broken.
>
> I could depend on version 1.5.11 directly, without using a version range,
> but Maven considers this a soft version dependency and will ignore it as
> needed.
>
> It is apparent that there is no reliable way to define a compatibility
> range in Maven. I feel that this should be a major concern to all Maven
> users and developers.
>
> It would be a shame for all the effort made by the Maven community to make
> software builds stable and reproducible to be undermined by consistent,
> predictable breakage described above.
>
> I have read in mailing list archives that the suggested way of excluding
> all 1.8.0 pre-release version is to define an exclusive upper bound as
> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with
> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a user to
> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>
> My proposal is that the qualifier is ignored when comparing a version to
> the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
> considered to fall outside of the version range. Importantly, it should
> only be for the special case of comparing to the version number in an
> exclusive upper bound.
>
> If the powers that be see fit, an exception could be made for service pack
> qualifiers, which according to one web page on Maven version ordering I
> read, should be sorted after the release, although I would prefer to see
> Maven more closely aligned to SemVer, where all qualified version numbers
> are considered pre-release versions. I consider 1.7.2 a better version
> number than 1.7.1-sp1.
>
> Ultimately, I would like to be able to make things as easy as possible for
> users depending on a library that adheres to SemVer, to define a
> compatibility range like: [1.4.0,2.0.0). I see no reason why it should not
> be as easy as that.
>
> Please consider fixing this soon.
>
> I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
> signup link on this page displays an error: http://maven.apache.org/users/
> **getting-help.html <http://maven.apache.org/users/getting-help.html>
>
> Jira issue MNG-3092, reported over 5 years ago, is related to this issue,
> but the initial report is for a similar issue, not this issue. The issue I
> describe above is reported and discussed in the comments for MNG-3092
> though.
>
> Thanks,
> Jesse
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Paul French
+1

I agree with Jesse.

A version range like [1.7,1.8) should exclude any artifact that starts
with 1.8

Then maven (or aether) would respect semantic versioning rules.

We use version ranges/semantic versioning and API analysis to ensure our
artifacts are versioned correctly. Sometimes we get caught out by what
Jesse outlined below.


On 27/09/2012 15:51, Stephen Connolly wrote:

> On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>
>> Dear Maven Community,
>>
>> I am writing to beg you to fix the problems with the version ranges in
>> Maven 3.0.5, specifically regarding the defining compatible version ranges.
>>
>> I am using Maven 3.0.4. I have a simple project that depends on
>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define the
>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
>> version 1.6.0-alpha2 is linked in.
>>
>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>> released it would probably break again.
>>
>> This is all too counter-intuitive. The current version of SLF4J is 1.7.1.
>> If my project was to be built against it, knowing that there is a
>> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J does
>> not adhere to SemVer), I would like to define my version range for
>> slf4j-api as [1.7.0,1.8.0). I
>
> I think you do [1.7.0,1.8.0-!)
>
> but that might just include 1.8.0-SNAPSHOT
>
>
>> have no way of knowing before the time what type of -RC0, -alpha2
>> qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.
>>
>> However, when 1.8.0-alpha2 is released with incompatible changes, my build
>> will immediately be broken.
>>
>> I could depend on version 1.5.11 directly, without using a version range,
>> but Maven considers this a soft version dependency and will ignore it as
>> needed.
>>
>> It is apparent that there is no reliable way to define a compatibility
>> range in Maven. I feel that this should be a major concern to all Maven
>> users and developers.
>>
>> It would be a shame for all the effort made by the Maven community to make
>> software builds stable and reproducible to be undermined by consistent,
>> predictable breakage described above.
>>
>> I have read in mailing list archives that the suggested way of excluding
>> all 1.8.0 pre-release version is to define an exclusive upper bound as
>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with
>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a user to
>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>
>> My proposal is that the qualifier is ignored when comparing a version to
>> the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>> considered to fall outside of the version range. Importantly, it should
>> only be for the special case of comparing to the version number in an
>> exclusive upper bound.
>>
>> If the powers that be see fit, an exception could be made for service pack
>> qualifiers, which according to one web page on Maven version ordering I
>> read, should be sorted after the release, although I would prefer to see
>> Maven more closely aligned to SemVer, where all qualified version numbers
>> are considered pre-release versions. I consider 1.7.2 a better version
>> number than 1.7.1-sp1.
>>
>> Ultimately, I would like to be able to make things as easy as possible for
>> users depending on a library that adheres to SemVer, to define a
>> compatibility range like: [1.4.0,2.0.0). I see no reason why it should not
>> be as easy as that.
>>
>> Please consider fixing this soon.
>>
>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
>> signup link on this page displays an error: http://maven.apache.org/users/
>> **getting-help.html <http://maven.apache.org/users/getting-help.html>
>>
>> Jira issue MNG-3092, reported over 5 years ago, is related to this issue,
>> but the initial report is for a similar issue, not this issue. The issue I
>> describe above is reported and discussed in the comments for MNG-3092
>> though.
>>
>> Thanks,
>> Jesse
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Joachim Van der Auwera (PROGS bvba)
In reply to this post by Jesse Long
Why not use
[1.7.0,1.7.99]

Just remember this when the project reaches revision 100 :-)

On 27-09-12 15:41, Jesse Long wrote:

> Dear Maven Community,
>
> I am writing to beg you to fix the problems with the version ranges in
> Maven 3.0.5, specifically regarding the defining compatible version
> ranges.
>
> I am using Maven 3.0.4. I have a simple project that depends on
> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define
> the version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api
> version 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
> slf4j-api version 1.6.0-alpha2 is linked in.
>
> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
> released it would probably break again.
>
> This is all too counter-intuitive. The current version of SLF4J is
> 1.7.1. If my project was to be built against it, knowing that there is
> a likelihood of an incompatible change being introduced in 1.8.0
> (SLF4J does not adhere to SemVer), I would like to define my version
> range for slf4j-api as [1.7.0,1.8.0). I have no way of knowing before
> the time what type of -RC0, -alpha2 qualified releases will be made
> for 1.8.0, so I can only exclude 1.8.0.
>
> However, when 1.8.0-alpha2 is released with incompatible changes, my
> build will immediately be broken.
>
> I could depend on version 1.5.11 directly, without using a version
> range, but Maven considers this a soft version dependency and will
> ignore it as needed.
>
> It is apparent that there is no reliable way to define a compatibility
> range in Maven. I feel that this should be a major concern to all
> Maven users and developers.
>
> It would be a shame for all the effort made by the Maven community to
> make software builds stable and reproducible to be undermined by
> consistent, predictable breakage described above.
>
> I have read in mailing list archives that the suggested way of
> excluding all 1.8.0 pre-release version is to define an exclusive
> upper bound as 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As
> demonstrated above with 1.6.0-RC0, this does not work. Also, it makes
> no sense at all for a user to wish to include 1.8.0-SNAPSHOT and not
> 1.8.0.
>
> My proposal is that the qualifier is ignored when comparing a version
> to the version number declared in an exclusive upper bound. ie.
> 1.6.0-xyz should be considered equal to 1.6.0 in [1.5.0,1.6.0), and
> therefore considered to fall outside of the version range.
> Importantly, it should only be for the special case of comparing to
> the version number in an exclusive upper bound.
>
> If the powers that be see fit, an exception could be made for service
> pack qualifiers, which according to one web page on Maven version
> ordering I read, should be sorted after the release, although I would
> prefer to see Maven more closely aligned to SemVer, where all
> qualified version numbers are considered pre-release versions. I
> consider 1.7.2 a better version number than 1.7.1-sp1.
>
> Ultimately, I would like to be able to make things as easy as possible
> for users depending on a library that adheres to SemVer, to define a
> compatibility range like: [1.4.0,2.0.0). I see no reason why it should
> not be as easy as that.
>
> Please consider fixing this soon.
>
> I have not logged a Jira issue, as I cannot log into CodeHaus Jira.
> The signup link on this page displays an error:
> http://maven.apache.org/users/getting-help.html
>
> Jira issue MNG-3092, reported over 5 years ago, is related to this
> issue, but the initial report is for a similar issue, not this issue.
> The issue I describe above is reported and discussed in the comments
> for MNG-3092 though.
>
> Thanks,
> Jesse
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Hervé BOUTEMY
In reply to this post by Paul French
I understand that many people get caught

But what do you expect from [1.7,1.8]?
And [1.7,1.8-beta)?

The actual semantic is pure mathematical range, including or excluding an
extreme

since 1.8-alpha<1.8-beta-<1.8-rc<1.8-SNAPSHOT<1.8, it's pure math
IMHO, anything that doesn't conform mathematical range will have some
unexpected behaviour sometime

Yes, people need to learn that they usually want [1.7,1.8-alpha-SNAPSHOT) if
they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
Or we need to create another notation and define its semantics precisely

Regards,

Hervé

Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :

> +1
>
> I agree with Jesse.
>
> A version range like [1.7,1.8) should exclude any artifact that starts
> with 1.8
>
> Then maven (or aether) would respect semantic versioning rules.
>
> We use version ranges/semantic versioning and API analysis to ensure our
> artifacts are versioned correctly. Sometimes we get caught out by what
> Jesse outlined below.
>
> On 27/09/2012 15:51, Stephen Connolly wrote:
> > On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
> >> Dear Maven Community,
> >>
> >> I am writing to beg you to fix the problems with the version ranges in
> >> Maven 3.0.5, specifically regarding the defining compatible version
> >> ranges.
> >>
> >> I am using Maven 3.0.4. I have a simple project that depends on
> >> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
> >> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define
> >> the
> >> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
> >> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
> >> version 1.6.0-alpha2 is linked in.
> >>
> >> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
> >> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
> >> released it would probably break again.
> >>
> >> This is all too counter-intuitive. The current version of SLF4J is 1.7.1.
> >> If my project was to be built against it, knowing that there is a
> >> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
> >> does
> >> not adhere to SemVer), I would like to define my version range for
> >> slf4j-api as [1.7.0,1.8.0). I
> >
> > I think you do [1.7.0,1.8.0-!)
> >
> > but that might just include 1.8.0-SNAPSHOT
> >
> >> have no way of knowing before the time what type of -RC0, -alpha2
> >> qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.
> >>
> >> However, when 1.8.0-alpha2 is released with incompatible changes, my
> >> build
> >> will immediately be broken.
> >>
> >> I could depend on version 1.5.11 directly, without using a version range,
> >> but Maven considers this a soft version dependency and will ignore it as
> >> needed.
> >>
> >> It is apparent that there is no reliable way to define a compatibility
> >> range in Maven. I feel that this should be a major concern to all Maven
> >> users and developers.
> >>
> >> It would be a shame for all the effort made by the Maven community to
> >> make
> >> software builds stable and reproducible to be undermined by consistent,
> >> predictable breakage described above.
> >>
> >> I have read in mailing list archives that the suggested way of excluding
> >> all 1.8.0 pre-release version is to define an exclusive upper bound as
> >> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with
> >> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a user
> >> to
> >> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
> >>
> >> My proposal is that the qualifier is ignored when comparing a version to
> >> the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
> >> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
> >> considered to fall outside of the version range. Importantly, it should
> >> only be for the special case of comparing to the version number in an
> >> exclusive upper bound.
> >>
> >> If the powers that be see fit, an exception could be made for service
> >> pack
> >> qualifiers, which according to one web page on Maven version ordering I
> >> read, should be sorted after the release, although I would prefer to see
> >> Maven more closely aligned to SemVer, where all qualified version numbers
> >> are considered pre-release versions. I consider 1.7.2 a better version
> >> number than 1.7.1-sp1.
> >>
> >> Ultimately, I would like to be able to make things as easy as possible
> >> for
> >> users depending on a library that adheres to SemVer, to define a
> >> compatibility range like: [1.4.0,2.0.0). I see no reason why it should
> >> not
> >> be as easy as that.
> >>
> >> Please consider fixing this soon.
> >>
> >> I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
> >> signup link on this page displays an error:
> >> http://maven.apache.org/users/
> >> **getting-help.html <http://maven.apache.org/users/getting-help.html>
> >>
> >> Jira issue MNG-3092, reported over 5 years ago, is related to this issue,
> >> but the initial report is for a similar issue, not this issue. The issue
> >> I
> >> describe above is reported and discussed in the comments for MNG-3092
> >> though.
> >>
> >> Thanks,
> >> Jesse
> >>
> >> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail:
> >> users-unsubscribe@maven.**apache.org<[hidden email]>
> >> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Hervé BOUTEMY
In reply to this post by Jesse Long
Le jeudi 27 septembre 2012 15:41:25 Jesse Long a écrit :
> I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
> signup link on this page displays an error:
> http://maven.apache.org/users/getting-help.html

thanks for the report
I updated the link, should be visible in the page soon

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Paul French
In reply to this post by Hervé BOUTEMY
Okay I see the problem.

How about allowing a user to plugin a Version class that implements
Comparator

   class MavenVersion implements Comparable<MavenVersion>
   {
     public int compareTo(MavenVersion o)
     {
       // your implementation
     }
   }

Then we can all do whatever we need.

On 27/09/2012 21:40, Hervé BOUTEMY wrote:

> I understand that many people get caught
>
> But what do you expect from [1.7,1.8]?
> And [1.7,1.8-beta)?
>
> The actual semantic is pure mathematical range, including or excluding an
> extreme
>
> since 1.8-alpha<1.8-beta-<1.8-rc<1.8-SNAPSHOT<1.8, it's pure math
> IMHO, anything that doesn't conform mathematical range will have some
> unexpected behaviour sometime
>
> Yes, people need to learn that they usually want [1.7,1.8-alpha-SNAPSHOT) if
> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
> Or we need to create another notation and define its semantics precisely
>
> Regards,
>
> Hervé
>
> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
>> +1
>>
>> I agree with Jesse.
>>
>> A version range like [1.7,1.8) should exclude any artifact that starts
>> with 1.8
>>
>> Then maven (or aether) would respect semantic versioning rules.
>>
>> We use version ranges/semantic versioning and API analysis to ensure our
>> artifacts are versioned correctly. Sometimes we get caught out by what
>> Jesse outlined below.
>>
>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>> On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>>>> Dear Maven Community,
>>>>
>>>> I am writing to beg you to fix the problems with the version ranges in
>>>> Maven 3.0.5, specifically regarding the defining compatible version
>>>> ranges.
>>>>
>>>> I am using Maven 3.0.4. I have a simple project that depends on
>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define
>>>> the
>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
>>>> version 1.6.0-alpha2 is linked in.
>>>>
>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>>>> released it would probably break again.
>>>>
>>>> This is all too counter-intuitive. The current version of SLF4J is 1.7.1.
>>>> If my project was to be built against it, knowing that there is a
>>>> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
>>>> does
>>>> not adhere to SemVer), I would like to define my version range for
>>>> slf4j-api as [1.7.0,1.8.0). I
>>> I think you do [1.7.0,1.8.0-!)
>>>
>>> but that might just include 1.8.0-SNAPSHOT
>>>
>>>> have no way of knowing before the time what type of -RC0, -alpha2
>>>> qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.
>>>>
>>>> However, when 1.8.0-alpha2 is released with incompatible changes, my
>>>> build
>>>> will immediately be broken.
>>>>
>>>> I could depend on version 1.5.11 directly, without using a version range,
>>>> but Maven considers this a soft version dependency and will ignore it as
>>>> needed.
>>>>
>>>> It is apparent that there is no reliable way to define a compatibility
>>>> range in Maven. I feel that this should be a major concern to all Maven
>>>> users and developers.
>>>>
>>>> It would be a shame for all the effort made by the Maven community to
>>>> make
>>>> software builds stable and reproducible to be undermined by consistent,
>>>> predictable breakage described above.
>>>>
>>>> I have read in mailing list archives that the suggested way of excluding
>>>> all 1.8.0 pre-release version is to define an exclusive upper bound as
>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with
>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a user
>>>> to
>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>>>
>>>> My proposal is that the qualifier is ignored when comparing a version to
>>>> the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>>>> considered to fall outside of the version range. Importantly, it should
>>>> only be for the special case of comparing to the version number in an
>>>> exclusive upper bound.
>>>>
>>>> If the powers that be see fit, an exception could be made for service
>>>> pack
>>>> qualifiers, which according to one web page on Maven version ordering I
>>>> read, should be sorted after the release, although I would prefer to see
>>>> Maven more closely aligned to SemVer, where all qualified version numbers
>>>> are considered pre-release versions. I consider 1.7.2 a better version
>>>> number than 1.7.1-sp1.
>>>>
>>>> Ultimately, I would like to be able to make things as easy as possible
>>>> for
>>>> users depending on a library that adheres to SemVer, to define a
>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it should
>>>> not
>>>> be as easy as that.
>>>>
>>>> Please consider fixing this soon.
>>>>
>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
>>>> signup link on this page displays an error:
>>>> http://maven.apache.org/users/
>>>> **getting-help.html <http://maven.apache.org/users/getting-help.html>
>>>>
>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this issue,
>>>> but the initial report is for a similar issue, not this issue. The issue
>>>> I
>>>> describe above is reported and discussed in the comments for MNG-3092
>>>> though.
>>>>
>>>> Thanks,
>>>> Jesse
>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail:
>>>> users-unsubscribe@maven.**apache.org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

stephenconnolly
when is that class applied?

each dependency would have its own comparator, as each dependency has its
own versioning rules.

and then don't start on epoch's (i.e. where the versioning rules change
from under your feet mid sequence

It's tempting... but dangerous... the closest I have come up with is the
rulesets hack from versions-maven-plugin @ mojo... but even that has
issues... hence why I haven't pushed it further.

-Stephen

On 27 September 2012 22:19, Paul French <[hidden email]> wrote:

> Okay I see the problem.
>
> How about allowing a user to plugin a Version class that implements
> Comparator
>
>   class MavenVersion implements Comparable<MavenVersion>
>   {
>     public int compareTo(MavenVersion o)
>     {
>       // your implementation
>     }
>   }
>
> Then we can all do whatever we need.
>
>
> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>
>> I understand that many people get caught
>>
>> But what do you expect from [1.7,1.8]?
>> And [1.7,1.8-beta)?
>>
>> The actual semantic is pure mathematical range, including or excluding an
>> extreme
>>
>> since 1.8-alpha<1.8-beta-<1.8-rc<1.**8-SNAPSHOT<1.8, it's pure math
>> IMHO, anything that doesn't conform mathematical range will have some
>> unexpected behaviour sometime
>>
>> Yes, people need to learn that they usually want [1.7,1.8-alpha-SNAPSHOT)
>> if
>> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
>> Or we need to create another notation and define its semantics precisely
>>
>> Regards,
>>
>> Hervé
>>
>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
>>
>>> +1
>>>
>>> I agree with Jesse.
>>>
>>> A version range like [1.7,1.8) should exclude any artifact that starts
>>> with 1.8
>>>
>>> Then maven (or aether) would respect semantic versioning rules.
>>>
>>> We use version ranges/semantic versioning and API analysis to ensure our
>>> artifacts are versioned correctly. Sometimes we get caught out by what
>>> Jesse outlined below.
>>>
>>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>>
>>>> On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>>>>
>>>>> Dear Maven Community,
>>>>>
>>>>> I am writing to beg you to fix the problems with the version ranges in
>>>>> Maven 3.0.5, specifically regarding the defining compatible version
>>>>> ranges.
>>>>>
>>>>> I am using Maven 3.0.4. I have a simple project that depends on
>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define
>>>>> the
>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
>>>>> version 1.6.0-alpha2 is linked in.
>>>>>
>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>>>>> released it would probably break again.
>>>>>
>>>>> This is all too counter-intuitive. The current version of SLF4J is
>>>>> 1.7.1.
>>>>> If my project was to be built against it, knowing that there is a
>>>>> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
>>>>> does
>>>>> not adhere to SemVer), I would like to define my version range for
>>>>> slf4j-api as [1.7.0,1.8.0). I
>>>>>
>>>> I think you do [1.7.0,1.8.0-!)
>>>>
>>>> but that might just include 1.8.0-SNAPSHOT
>>>>
>>>>  have no way of knowing before the time what type of -RC0, -alpha2
>>>>> qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.
>>>>>
>>>>> However, when 1.8.0-alpha2 is released with incompatible changes, my
>>>>> build
>>>>> will immediately be broken.
>>>>>
>>>>> I could depend on version 1.5.11 directly, without using a version
>>>>> range,
>>>>> but Maven considers this a soft version dependency and will ignore it
>>>>> as
>>>>> needed.
>>>>>
>>>>> It is apparent that there is no reliable way to define a compatibility
>>>>> range in Maven. I feel that this should be a major concern to all Maven
>>>>> users and developers.
>>>>>
>>>>> It would be a shame for all the effort made by the Maven community to
>>>>> make
>>>>> software builds stable and reproducible to be undermined by consistent,
>>>>> predictable breakage described above.
>>>>>
>>>>> I have read in mailing list archives that the suggested way of
>>>>> excluding
>>>>> all 1.8.0 pre-release version is to define an exclusive upper bound as
>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
>>>>> with
>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a
>>>>> user
>>>>> to
>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>>>>
>>>>> My proposal is that the qualifier is ignored when comparing a version
>>>>> to
>>>>> the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>>>>> considered to fall outside of the version range. Importantly, it should
>>>>> only be for the special case of comparing to the version number in an
>>>>> exclusive upper bound.
>>>>>
>>>>> If the powers that be see fit, an exception could be made for service
>>>>> pack
>>>>> qualifiers, which according to one web page on Maven version ordering I
>>>>> read, should be sorted after the release, although I would prefer to
>>>>> see
>>>>> Maven more closely aligned to SemVer, where all qualified version
>>>>> numbers
>>>>> are considered pre-release versions. I consider 1.7.2 a better version
>>>>> number than 1.7.1-sp1.
>>>>>
>>>>> Ultimately, I would like to be able to make things as easy as possible
>>>>> for
>>>>> users depending on a library that adheres to SemVer, to define a
>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it should
>>>>> not
>>>>> be as easy as that.
>>>>>
>>>>> Please consider fixing this soon.
>>>>>
>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
>>>>> signup link on this page displays an error:
>>>>> http://maven.apache.org/users/
>>>>> **getting-help.html <http://maven.apache.org/**users/getting-help.html<http://maven.apache.org/users/getting-help.html>
>>>>> >
>>>>>
>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this
>>>>> issue,
>>>>> but the initial report is for a similar issue, not this issue. The
>>>>> issue
>>>>> I
>>>>> describe above is reported and discussed in the comments for MNG-3092
>>>>> though.
>>>>>
>>>>> Thanks,
>>>>> Jesse
>>>>>
>>>>> ------------------------------****----------------------------**
>>>>> --**---------
>>>>> To unsubscribe, e-mail:
>>>>> users-unsubscribe@maven.**apac**he.org <http://apache.org><
>>>>> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>> >
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Paul French
I would only want the same version rules applied to all artifacts, not
on a per artifact basis, that would be a nightmare! I understand that
people who produce artifacts have their own versioning rules. However we
can take that into account in our version ranging.

Usually for 3rd party artifacts we have a very narrow version range
since we cannot trust the producer of that artifact not to break their
current API in later versions unless they support semantic versioning.

On 27/09/2012 22:29, Stephen Connolly wrote:

> when is that class applied?
>
> each dependency would have its own comparator, as each dependency has its
> own versioning rules.
>
> and then don't start on epoch's (i.e. where the versioning rules change
> from under your feet mid sequence
>
> It's tempting... but dangerous... the closest I have come up with is the
> rulesets hack from versions-maven-plugin @ mojo... but even that has
> issues... hence why I haven't pushed it further.
>
> -Stephen
>
> On 27 September 2012 22:19, Paul French <[hidden email]> wrote:
>
>> Okay I see the problem.
>>
>> How about allowing a user to plugin a Version class that implements
>> Comparator
>>
>>    class MavenVersion implements Comparable<MavenVersion>
>>    {
>>      public int compareTo(MavenVersion o)
>>      {
>>        // your implementation
>>      }
>>    }
>>
>> Then we can all do whatever we need.
>>
>>
>> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>>
>>> I understand that many people get caught
>>>
>>> But what do you expect from [1.7,1.8]?
>>> And [1.7,1.8-beta)?
>>>
>>> The actual semantic is pure mathematical range, including or excluding an
>>> extreme
>>>
>>> since 1.8-alpha<1.8-beta-<1.8-rc<1.**8-SNAPSHOT<1.8, it's pure math
>>> IMHO, anything that doesn't conform mathematical range will have some
>>> unexpected behaviour sometime
>>>
>>> Yes, people need to learn that they usually want [1.7,1.8-alpha-SNAPSHOT)
>>> if
>>> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
>>> Or we need to create another notation and define its semantics precisely
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
>>>
>>>> +1
>>>>
>>>> I agree with Jesse.
>>>>
>>>> A version range like [1.7,1.8) should exclude any artifact that starts
>>>> with 1.8
>>>>
>>>> Then maven (or aether) would respect semantic versioning rules.
>>>>
>>>> We use version ranges/semantic versioning and API analysis to ensure our
>>>> artifacts are versioned correctly. Sometimes we get caught out by what
>>>> Jesse outlined below.
>>>>
>>>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>>>
>>>>> On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>>>>>
>>>>>> Dear Maven Community,
>>>>>>
>>>>>> I am writing to beg you to fix the problems with the version ranges in
>>>>>> Maven 3.0.5, specifically regarding the defining compatible version
>>>>>> ranges.
>>>>>>
>>>>>> I am using Maven 3.0.4. I have a simple project that depends on
>>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
>>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define
>>>>>> the
>>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
>>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
>>>>>> version 1.6.0-alpha2 is linked in.
>>>>>>
>>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
>>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>>>>>> released it would probably break again.
>>>>>>
>>>>>> This is all too counter-intuitive. The current version of SLF4J is
>>>>>> 1.7.1.
>>>>>> If my project was to be built against it, knowing that there is a
>>>>>> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
>>>>>> does
>>>>>> not adhere to SemVer), I would like to define my version range for
>>>>>> slf4j-api as [1.7.0,1.8.0). I
>>>>>>
>>>>> I think you do [1.7.0,1.8.0-!)
>>>>>
>>>>> but that might just include 1.8.0-SNAPSHOT
>>>>>
>>>>>   have no way of knowing before the time what type of -RC0, -alpha2
>>>>>> qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.
>>>>>>
>>>>>> However, when 1.8.0-alpha2 is released with incompatible changes, my
>>>>>> build
>>>>>> will immediately be broken.
>>>>>>
>>>>>> I could depend on version 1.5.11 directly, without using a version
>>>>>> range,
>>>>>> but Maven considers this a soft version dependency and will ignore it
>>>>>> as
>>>>>> needed.
>>>>>>
>>>>>> It is apparent that there is no reliable way to define a compatibility
>>>>>> range in Maven. I feel that this should be a major concern to all Maven
>>>>>> users and developers.
>>>>>>
>>>>>> It would be a shame for all the effort made by the Maven community to
>>>>>> make
>>>>>> software builds stable and reproducible to be undermined by consistent,
>>>>>> predictable breakage described above.
>>>>>>
>>>>>> I have read in mailing list archives that the suggested way of
>>>>>> excluding
>>>>>> all 1.8.0 pre-release version is to define an exclusive upper bound as
>>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
>>>>>> with
>>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a
>>>>>> user
>>>>>> to
>>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>>>>>
>>>>>> My proposal is that the qualifier is ignored when comparing a version
>>>>>> to
>>>>>> the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
>>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>>>>>> considered to fall outside of the version range. Importantly, it should
>>>>>> only be for the special case of comparing to the version number in an
>>>>>> exclusive upper bound.
>>>>>>
>>>>>> If the powers that be see fit, an exception could be made for service
>>>>>> pack
>>>>>> qualifiers, which according to one web page on Maven version ordering I
>>>>>> read, should be sorted after the release, although I would prefer to
>>>>>> see
>>>>>> Maven more closely aligned to SemVer, where all qualified version
>>>>>> numbers
>>>>>> are considered pre-release versions. I consider 1.7.2 a better version
>>>>>> number than 1.7.1-sp1.
>>>>>>
>>>>>> Ultimately, I would like to be able to make things as easy as possible
>>>>>> for
>>>>>> users depending on a library that adheres to SemVer, to define a
>>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it should
>>>>>> not
>>>>>> be as easy as that.
>>>>>>
>>>>>> Please consider fixing this soon.
>>>>>>
>>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
>>>>>> signup link on this page displays an error:
>>>>>> http://maven.apache.org/users/
>>>>>> **getting-help.html <http://maven.apache.org/**users/getting-help.html<http://maven.apache.org/users/getting-help.html>
>>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this
>>>>>> issue,
>>>>>> but the initial report is for a similar issue, not this issue. The
>>>>>> issue
>>>>>> I
>>>>>> describe above is reported and discussed in the comments for MNG-3092
>>>>>> though.
>>>>>>
>>>>>> Thanks,
>>>>>> Jesse
>>>>>>
>>>>>> ------------------------------****----------------------------**
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail:
>>>>>> users-unsubscribe@maven.**apac**he.org <http://apache.org><
>>>>>> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

stephenconnolly
Well that is a recipe for disaster. rules only make sense within the scope
of the artifacts they apply to.

This is kind of why version ranges are next to useless from a practical PoV
anyway

On 27 September 2012 23:05, Paul French <[hidden email]> wrote:

> I would only want the same version rules applied to all artifacts, not on
> a per artifact basis, that would be a nightmare! I understand that people
> who produce artifacts have their own versioning rules. However we can take
> that into account in our version ranging.
>
> Usually for 3rd party artifacts we have a very narrow version range since
> we cannot trust the producer of that artifact not to break their current
> API in later versions unless they support semantic versioning.
>
>
> On 27/09/2012 22:29, Stephen Connolly wrote:
>
>> when is that class applied?
>>
>> each dependency would have its own comparator, as each dependency has its
>> own versioning rules.
>>
>> and then don't start on epoch's (i.e. where the versioning rules change
>> from under your feet mid sequence
>>
>> It's tempting... but dangerous... the closest I have come up with is the
>> rulesets hack from versions-maven-plugin @ mojo... but even that has
>> issues... hence why I haven't pushed it further.
>>
>> -Stephen
>>
>> On 27 September 2012 22:19, Paul French <[hidden email]> wrote:
>>
>>  Okay I see the problem.
>>>
>>> How about allowing a user to plugin a Version class that implements
>>> Comparator
>>>
>>>    class MavenVersion implements Comparable<MavenVersion>
>>>    {
>>>      public int compareTo(MavenVersion o)
>>>      {
>>>        // your implementation
>>>      }
>>>    }
>>>
>>> Then we can all do whatever we need.
>>>
>>>
>>> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>>>
>>>  I understand that many people get caught
>>>>
>>>> But what do you expect from [1.7,1.8]?
>>>> And [1.7,1.8-beta)?
>>>>
>>>> The actual semantic is pure mathematical range, including or excluding
>>>> an
>>>> extreme
>>>>
>>>> since 1.8-alpha<1.8-beta-<1.8-rc<1.****8-SNAPSHOT<1.8, it's pure math
>>>>
>>>> IMHO, anything that doesn't conform mathematical range will have some
>>>> unexpected behaviour sometime
>>>>
>>>> Yes, people need to learn that they usually want
>>>> [1.7,1.8-alpha-SNAPSHOT)
>>>> if
>>>> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
>>>> Or we need to create another notation and define its semantics precisely
>>>>
>>>> Regards,
>>>>
>>>> Hervé
>>>>
>>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
>>>>
>>>>  +1
>>>>>
>>>>> I agree with Jesse.
>>>>>
>>>>> A version range like [1.7,1.8) should exclude any artifact that starts
>>>>> with 1.8
>>>>>
>>>>> Then maven (or aether) would respect semantic versioning rules.
>>>>>
>>>>> We use version ranges/semantic versioning and API analysis to ensure
>>>>> our
>>>>> artifacts are versioned correctly. Sometimes we get caught out by what
>>>>> Jesse outlined below.
>>>>>
>>>>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>>>>
>>>>>  On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>>>>>>
>>>>>>  Dear Maven Community,
>>>>>>>
>>>>>>> I am writing to beg you to fix the problems with the version ranges
>>>>>>> in
>>>>>>> Maven 3.0.5, specifically regarding the defining compatible version
>>>>>>> ranges.
>>>>>>>
>>>>>>> I am using Maven 3.0.4. I have a simple project that depends on
>>>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
>>>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
>>>>>>> define
>>>>>>> the
>>>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
>>>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
>>>>>>> slf4j-api
>>>>>>> version 1.6.0-alpha2 is linked in.
>>>>>>>
>>>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then
>>>>>>> the
>>>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>>>>>>> released it would probably break again.
>>>>>>>
>>>>>>> This is all too counter-intuitive. The current version of SLF4J is
>>>>>>> 1.7.1.
>>>>>>> If my project was to be built against it, knowing that there is a
>>>>>>> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
>>>>>>> does
>>>>>>> not adhere to SemVer), I would like to define my version range for
>>>>>>> slf4j-api as [1.7.0,1.8.0). I
>>>>>>>
>>>>>>>  I think you do [1.7.0,1.8.0-!)
>>>>>>
>>>>>> but that might just include 1.8.0-SNAPSHOT
>>>>>>
>>>>>>   have no way of knowing before the time what type of -RC0, -alpha2
>>>>>>
>>>>>>> qualified releases will be made for 1.8.0, so I can only exclude
>>>>>>> 1.8.0.
>>>>>>>
>>>>>>> However, when 1.8.0-alpha2 is released with incompatible changes, my
>>>>>>> build
>>>>>>> will immediately be broken.
>>>>>>>
>>>>>>> I could depend on version 1.5.11 directly, without using a version
>>>>>>> range,
>>>>>>> but Maven considers this a soft version dependency and will ignore it
>>>>>>> as
>>>>>>> needed.
>>>>>>>
>>>>>>> It is apparent that there is no reliable way to define a
>>>>>>> compatibility
>>>>>>> range in Maven. I feel that this should be a major concern to all
>>>>>>> Maven
>>>>>>> users and developers.
>>>>>>>
>>>>>>> It would be a shame for all the effort made by the Maven community to
>>>>>>> make
>>>>>>> software builds stable and reproducible to be undermined by
>>>>>>> consistent,
>>>>>>> predictable breakage described above.
>>>>>>>
>>>>>>> I have read in mailing list archives that the suggested way of
>>>>>>> excluding
>>>>>>> all 1.8.0 pre-release version is to define an exclusive upper bound
>>>>>>> as
>>>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
>>>>>>> with
>>>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a
>>>>>>> user
>>>>>>> to
>>>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>>>>>>
>>>>>>> My proposal is that the qualifier is ignored when comparing a version
>>>>>>> to
>>>>>>> the version number declared in an exclusive upper bound. ie.
>>>>>>> 1.6.0-xyz
>>>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>>>>>>> considered to fall outside of the version range. Importantly, it
>>>>>>> should
>>>>>>> only be for the special case of comparing to the version number in an
>>>>>>> exclusive upper bound.
>>>>>>>
>>>>>>> If the powers that be see fit, an exception could be made for service
>>>>>>> pack
>>>>>>> qualifiers, which according to one web page on Maven version
>>>>>>> ordering I
>>>>>>> read, should be sorted after the release, although I would prefer to
>>>>>>> see
>>>>>>> Maven more closely aligned to SemVer, where all qualified version
>>>>>>> numbers
>>>>>>> are considered pre-release versions. I consider 1.7.2 a better
>>>>>>> version
>>>>>>> number than 1.7.1-sp1.
>>>>>>>
>>>>>>> Ultimately, I would like to be able to make things as easy as
>>>>>>> possible
>>>>>>> for
>>>>>>> users depending on a library that adheres to SemVer, to define a
>>>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it
>>>>>>> should
>>>>>>> not
>>>>>>> be as easy as that.
>>>>>>>
>>>>>>> Please consider fixing this soon.
>>>>>>>
>>>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira.
>>>>>>> The
>>>>>>> signup link on this page displays an error:
>>>>>>> http://maven.apache.org/users/
>>>>>>> **getting-help.html <http://maven.apache.org/****
>>>>>>> users/getting-help.html<http://maven.apache.org/**users/getting-help.html>
>>>>>>> <http:/**/maven.apache.org/users/**getting-help.html<http://maven.apache.org/users/getting-help.html>
>>>>>>> >
>>>>>>>
>>>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this
>>>>>>> issue,
>>>>>>> but the initial report is for a similar issue, not this issue. The
>>>>>>> issue
>>>>>>> I
>>>>>>> describe above is reported and discussed in the comments for MNG-3092
>>>>>>> though.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jesse
>>>>>>>
>>>>>>> ------------------------------******--------------------------**--**
>>>>>>> --**---------
>>>>>>> To unsubscribe, e-mail:
>>>>>>> users-unsubscribe@maven.****apac**he.org <http://apache.org><
>>>>>>> users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
>>>>>>> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>>> >
>>>>>>>
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>  ------------------------------****----------------------------**
>>>>>> --**
>>>>>>
>>>>> ---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>>> <users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>> >
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>  ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>> <users-unsubscribe@**maven.apache.org<[hidden email]>
>>>> >
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>  ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>> <users-unsubscribe@**maven.apache.org<[hidden email]>
>>> >
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Paul French
I have to disagree. Version ranges are very useful to us especially with
artifacts we control where we use semantic versioning and api analysis
to enforce this.

Artifacts we don't control the versioning of e.g SLF4J we nail down the
version we use.

Our product POM's can have 100's of version ranged artifacts

If we could plugin a version range class into maven (maven would ship
with a version range class with the rules it uses now), at least I would
then have a choice to replace it with an implementation I'm happier with.

Anyway it works for us as it is now, so I'm not going to lose any sleep
over it.

Cheers

On 27/09/2012 23:36, Stephen Connolly wrote:

> Well that is a recipe for disaster. rules only make sense within the scope
> of the artifacts they apply to.
>
> This is kind of why version ranges are next to useless from a practical PoV
> anyway
>
> On 27 September 2012 23:05, Paul French <[hidden email]> wrote:
>
>> I would only want the same version rules applied to all artifacts, not on
>> a per artifact basis, that would be a nightmare! I understand that people
>> who produce artifacts have their own versioning rules. However we can take
>> that into account in our version ranging.
>>
>> Usually for 3rd party artifacts we have a very narrow version range since
>> we cannot trust the producer of that artifact not to break their current
>> API in later versions unless they support semantic versioning.
>>
>>
>> On 27/09/2012 22:29, Stephen Connolly wrote:
>>
>>> when is that class applied?
>>>
>>> each dependency would have its own comparator, as each dependency has its
>>> own versioning rules.
>>>
>>> and then don't start on epoch's (i.e. where the versioning rules change
>>> from under your feet mid sequence
>>>
>>> It's tempting... but dangerous... the closest I have come up with is the
>>> rulesets hack from versions-maven-plugin @ mojo... but even that has
>>> issues... hence why I haven't pushed it further.
>>>
>>> -Stephen
>>>
>>> On 27 September 2012 22:19, Paul French <[hidden email]> wrote:
>>>
>>>   Okay I see the problem.
>>>> How about allowing a user to plugin a Version class that implements
>>>> Comparator
>>>>
>>>>     class MavenVersion implements Comparable<MavenVersion>
>>>>     {
>>>>       public int compareTo(MavenVersion o)
>>>>       {
>>>>         // your implementation
>>>>       }
>>>>     }
>>>>
>>>> Then we can all do whatever we need.
>>>>
>>>>
>>>> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>>>>
>>>>   I understand that many people get caught
>>>>> But what do you expect from [1.7,1.8]?
>>>>> And [1.7,1.8-beta)?
>>>>>
>>>>> The actual semantic is pure mathematical range, including or excluding
>>>>> an
>>>>> extreme
>>>>>
>>>>> since 1.8-alpha<1.8-beta-<1.8-rc<1.****8-SNAPSHOT<1.8, it's pure math
>>>>>
>>>>> IMHO, anything that doesn't conform mathematical range will have some
>>>>> unexpected behaviour sometime
>>>>>
>>>>> Yes, people need to learn that they usually want
>>>>> [1.7,1.8-alpha-SNAPSHOT)
>>>>> if
>>>>> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
>>>>> Or we need to create another notation and define its semantics precisely
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hervé
>>>>>
>>>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
>>>>>
>>>>>   +1
>>>>>> I agree with Jesse.
>>>>>>
>>>>>> A version range like [1.7,1.8) should exclude any artifact that starts
>>>>>> with 1.8
>>>>>>
>>>>>> Then maven (or aether) would respect semantic versioning rules.
>>>>>>
>>>>>> We use version ranges/semantic versioning and API analysis to ensure
>>>>>> our
>>>>>> artifacts are versioned correctly. Sometimes we get caught out by what
>>>>>> Jesse outlined below.
>>>>>>
>>>>>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>>>>>
>>>>>>   On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>>>>>>>   Dear Maven Community,
>>>>>>>> I am writing to beg you to fix the problems with the version ranges
>>>>>>>> in
>>>>>>>> Maven 3.0.5, specifically regarding the defining compatible version
>>>>>>>> ranges.
>>>>>>>>
>>>>>>>> I am using Maven 3.0.4. I have a simple project that depends on
>>>>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
>>>>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
>>>>>>>> define
>>>>>>>> the
>>>>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
>>>>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
>>>>>>>> slf4j-api
>>>>>>>> version 1.6.0-alpha2 is linked in.
>>>>>>>>
>>>>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then
>>>>>>>> the
>>>>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>>>>>>>> released it would probably break again.
>>>>>>>>
>>>>>>>> This is all too counter-intuitive. The current version of SLF4J is
>>>>>>>> 1.7.1.
>>>>>>>> If my project was to be built against it, knowing that there is a
>>>>>>>> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
>>>>>>>> does
>>>>>>>> not adhere to SemVer), I would like to define my version range for
>>>>>>>> slf4j-api as [1.7.0,1.8.0). I
>>>>>>>>
>>>>>>>>   I think you do [1.7.0,1.8.0-!)
>>>>>>> but that might just include 1.8.0-SNAPSHOT
>>>>>>>
>>>>>>>    have no way of knowing before the time what type of -RC0, -alpha2
>>>>>>>
>>>>>>>> qualified releases will be made for 1.8.0, so I can only exclude
>>>>>>>> 1.8.0.
>>>>>>>>
>>>>>>>> However, when 1.8.0-alpha2 is released with incompatible changes, my
>>>>>>>> build
>>>>>>>> will immediately be broken.
>>>>>>>>
>>>>>>>> I could depend on version 1.5.11 directly, without using a version
>>>>>>>> range,
>>>>>>>> but Maven considers this a soft version dependency and will ignore it
>>>>>>>> as
>>>>>>>> needed.
>>>>>>>>
>>>>>>>> It is apparent that there is no reliable way to define a
>>>>>>>> compatibility
>>>>>>>> range in Maven. I feel that this should be a major concern to all
>>>>>>>> Maven
>>>>>>>> users and developers.
>>>>>>>>
>>>>>>>> It would be a shame for all the effort made by the Maven community to
>>>>>>>> make
>>>>>>>> software builds stable and reproducible to be undermined by
>>>>>>>> consistent,
>>>>>>>> predictable breakage described above.
>>>>>>>>
>>>>>>>> I have read in mailing list archives that the suggested way of
>>>>>>>> excluding
>>>>>>>> all 1.8.0 pre-release version is to define an exclusive upper bound
>>>>>>>> as
>>>>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
>>>>>>>> with
>>>>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a
>>>>>>>> user
>>>>>>>> to
>>>>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>>>>>>>
>>>>>>>> My proposal is that the qualifier is ignored when comparing a version
>>>>>>>> to
>>>>>>>> the version number declared in an exclusive upper bound. ie.
>>>>>>>> 1.6.0-xyz
>>>>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>>>>>>>> considered to fall outside of the version range. Importantly, it
>>>>>>>> should
>>>>>>>> only be for the special case of comparing to the version number in an
>>>>>>>> exclusive upper bound.
>>>>>>>>
>>>>>>>> If the powers that be see fit, an exception could be made for service
>>>>>>>> pack
>>>>>>>> qualifiers, which according to one web page on Maven version
>>>>>>>> ordering I
>>>>>>>> read, should be sorted after the release, although I would prefer to
>>>>>>>> see
>>>>>>>> Maven more closely aligned to SemVer, where all qualified version
>>>>>>>> numbers
>>>>>>>> are considered pre-release versions. I consider 1.7.2 a better
>>>>>>>> version
>>>>>>>> number than 1.7.1-sp1.
>>>>>>>>
>>>>>>>> Ultimately, I would like to be able to make things as easy as
>>>>>>>> possible
>>>>>>>> for
>>>>>>>> users depending on a library that adheres to SemVer, to define a
>>>>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it
>>>>>>>> should
>>>>>>>> not
>>>>>>>> be as easy as that.
>>>>>>>>
>>>>>>>> Please consider fixing this soon.
>>>>>>>>
>>>>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira.
>>>>>>>> The
>>>>>>>> signup link on this page displays an error:
>>>>>>>> http://maven.apache.org/users/
>>>>>>>> **getting-help.html <http://maven.apache.org/****
>>>>>>>> users/getting-help.html<http://maven.apache.org/**users/getting-help.html>
>>>>>>>> <http:/**/maven.apache.org/users/**getting-help.html<http://maven.apache.org/users/getting-help.html>
>>>>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this
>>>>>>>> issue,
>>>>>>>> but the initial report is for a similar issue, not this issue. The
>>>>>>>> issue
>>>>>>>> I
>>>>>>>> describe above is reported and discussed in the comments for MNG-3092
>>>>>>>> though.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jesse
>>>>>>>>
>>>>>>>> ------------------------------******--------------------------**--**
>>>>>>>> --**---------
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> users-unsubscribe@maven.****apac**he.org <http://apache.org><
>>>>>>>> users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
>>>>>>>> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>   ------------------------------****----------------------------**
>>>>>>> --**
>>>>>>>
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>>>> <users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>   ------------------------------****----------------------------**
>>>>> --**---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>>> <users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>   ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>> <users-unsubscribe@**maven.apache.org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

stephenconnolly
My experience with versions-maven-plugin would show different, but each to
their own

On 27 September 2012 23:56, Paul French <[hidden email]> wrote:

> I have to disagree. Version ranges are very useful to us especially with
> artifacts we control where we use semantic versioning and api analysis to
> enforce this.
>
> Artifacts we don't control the versioning of e.g SLF4J we nail down the
> version we use.
>
> Our product POM's can have 100's of version ranged artifacts
>
> If we could plugin a version range class into maven (maven would ship with
> a version range class with the rules it uses now), at least I would then
> have a choice to replace it with an implementation I'm happier with.
>
> Anyway it works for us as it is now, so I'm not going to lose any sleep
> over it.
>
> Cheers
>
>
> On 27/09/2012 23:36, Stephen Connolly wrote:
>
>> Well that is a recipe for disaster. rules only make sense within the scope
>> of the artifacts they apply to.
>>
>> This is kind of why version ranges are next to useless from a practical
>> PoV
>> anyway
>>
>> On 27 September 2012 23:05, Paul French <[hidden email]> wrote:
>>
>>  I would only want the same version rules applied to all artifacts, not on
>>> a per artifact basis, that would be a nightmare! I understand that people
>>> who produce artifacts have their own versioning rules. However we can
>>> take
>>> that into account in our version ranging.
>>>
>>> Usually for 3rd party artifacts we have a very narrow version range since
>>> we cannot trust the producer of that artifact not to break their current
>>> API in later versions unless they support semantic versioning.
>>>
>>>
>>> On 27/09/2012 22:29, Stephen Connolly wrote:
>>>
>>>  when is that class applied?
>>>>
>>>> each dependency would have its own comparator, as each dependency has
>>>> its
>>>> own versioning rules.
>>>>
>>>> and then don't start on epoch's (i.e. where the versioning rules change
>>>> from under your feet mid sequence
>>>>
>>>> It's tempting... but dangerous... the closest I have come up with is the
>>>> rulesets hack from versions-maven-plugin @ mojo... but even that has
>>>> issues... hence why I haven't pushed it further.
>>>>
>>>> -Stephen
>>>>
>>>> On 27 September 2012 22:19, Paul French <[hidden email]> wrote:
>>>>
>>>>   Okay I see the problem.
>>>>
>>>>> How about allowing a user to plugin a Version class that implements
>>>>> Comparator
>>>>>
>>>>>     class MavenVersion implements Comparable<MavenVersion>
>>>>>     {
>>>>>       public int compareTo(MavenVersion o)
>>>>>       {
>>>>>         // your implementation
>>>>>       }
>>>>>     }
>>>>>
>>>>> Then we can all do whatever we need.
>>>>>
>>>>>
>>>>> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>>>>>
>>>>>   I understand that many people get caught
>>>>>
>>>>>> But what do you expect from [1.7,1.8]?
>>>>>> And [1.7,1.8-beta)?
>>>>>>
>>>>>> The actual semantic is pure mathematical range, including or excluding
>>>>>> an
>>>>>> extreme
>>>>>>
>>>>>> since 1.8-alpha<1.8-beta-<1.8-rc<1.******8-SNAPSHOT<1.8, it's pure
>>>>>> math
>>>>>>
>>>>>>
>>>>>> IMHO, anything that doesn't conform mathematical range will have some
>>>>>> unexpected behaviour sometime
>>>>>>
>>>>>> Yes, people need to learn that they usually want
>>>>>> [1.7,1.8-alpha-SNAPSHOT)
>>>>>> if
>>>>>> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
>>>>>> Or we need to create another notation and define its semantics
>>>>>> precisely
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Hervé
>>>>>>
>>>>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
>>>>>>
>>>>>>   +1
>>>>>>
>>>>>>> I agree with Jesse.
>>>>>>>
>>>>>>> A version range like [1.7,1.8) should exclude any artifact that
>>>>>>> starts
>>>>>>> with 1.8
>>>>>>>
>>>>>>> Then maven (or aether) would respect semantic versioning rules.
>>>>>>>
>>>>>>> We use version ranges/semantic versioning and API analysis to ensure
>>>>>>> our
>>>>>>> artifacts are versioned correctly. Sometimes we get caught out by
>>>>>>> what
>>>>>>> Jesse outlined below.
>>>>>>>
>>>>>>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>>>>>>
>>>>>>>   On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>>>>>>>
>>>>>>>>   Dear Maven Community,
>>>>>>>>
>>>>>>>>> I am writing to beg you to fix the problems with the version ranges
>>>>>>>>> in
>>>>>>>>> Maven 3.0.5, specifically regarding the defining compatible version
>>>>>>>>> ranges.
>>>>>>>>>
>>>>>>>>> I am using Maven 3.0.4. I have a simple project that depends on
>>>>>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range
>>>>>>>>> as
>>>>>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
>>>>>>>>> define
>>>>>>>>> the
>>>>>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api
>>>>>>>>> version
>>>>>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
>>>>>>>>> slf4j-api
>>>>>>>>> version 1.6.0-alpha2 is linked in.
>>>>>>>>>
>>>>>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then
>>>>>>>>> the
>>>>>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>>>>>>>>> released it would probably break again.
>>>>>>>>>
>>>>>>>>> This is all too counter-intuitive. The current version of SLF4J is
>>>>>>>>> 1.7.1.
>>>>>>>>> If my project was to be built against it, knowing that there is a
>>>>>>>>> likelihood of an incompatible change being introduced in 1.8.0
>>>>>>>>> (SLF4J
>>>>>>>>> does
>>>>>>>>> not adhere to SemVer), I would like to define my version range for
>>>>>>>>> slf4j-api as [1.7.0,1.8.0). I
>>>>>>>>>
>>>>>>>>>   I think you do [1.7.0,1.8.0-!)
>>>>>>>>>
>>>>>>>> but that might just include 1.8.0-SNAPSHOT
>>>>>>>>
>>>>>>>>    have no way of knowing before the time what type of -RC0, -alpha2
>>>>>>>>
>>>>>>>>  qualified releases will be made for 1.8.0, so I can only exclude
>>>>>>>>> 1.8.0.
>>>>>>>>>
>>>>>>>>> However, when 1.8.0-alpha2 is released with incompatible changes,
>>>>>>>>> my
>>>>>>>>> build
>>>>>>>>> will immediately be broken.
>>>>>>>>>
>>>>>>>>> I could depend on version 1.5.11 directly, without using a version
>>>>>>>>> range,
>>>>>>>>> but Maven considers this a soft version dependency and will ignore
>>>>>>>>> it
>>>>>>>>> as
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>>> It is apparent that there is no reliable way to define a
>>>>>>>>> compatibility
>>>>>>>>> range in Maven. I feel that this should be a major concern to all
>>>>>>>>> Maven
>>>>>>>>> users and developers.
>>>>>>>>>
>>>>>>>>> It would be a shame for all the effort made by the Maven community
>>>>>>>>> to
>>>>>>>>> make
>>>>>>>>> software builds stable and reproducible to be undermined by
>>>>>>>>> consistent,
>>>>>>>>> predictable breakage described above.
>>>>>>>>>
>>>>>>>>> I have read in mailing list archives that the suggested way of
>>>>>>>>> excluding
>>>>>>>>> all 1.8.0 pre-release version is to define an exclusive upper bound
>>>>>>>>> as
>>>>>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
>>>>>>>>> with
>>>>>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a
>>>>>>>>> user
>>>>>>>>> to
>>>>>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>>>>>>>>
>>>>>>>>> My proposal is that the qualifier is ignored when comparing a
>>>>>>>>> version
>>>>>>>>> to
>>>>>>>>> the version number declared in an exclusive upper bound. ie.
>>>>>>>>> 1.6.0-xyz
>>>>>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>>>>>>>>> considered to fall outside of the version range. Importantly, it
>>>>>>>>> should
>>>>>>>>> only be for the special case of comparing to the version number in
>>>>>>>>> an
>>>>>>>>> exclusive upper bound.
>>>>>>>>>
>>>>>>>>> If the powers that be see fit, an exception could be made for
>>>>>>>>> service
>>>>>>>>> pack
>>>>>>>>> qualifiers, which according to one web page on Maven version
>>>>>>>>> ordering I
>>>>>>>>> read, should be sorted after the release, although I would prefer
>>>>>>>>> to
>>>>>>>>> see
>>>>>>>>> Maven more closely aligned to SemVer, where all qualified version
>>>>>>>>> numbers
>>>>>>>>> are considered pre-release versions. I consider 1.7.2 a better
>>>>>>>>> version
>>>>>>>>> number than 1.7.1-sp1.
>>>>>>>>>
>>>>>>>>> Ultimately, I would like to be able to make things as easy as
>>>>>>>>> possible
>>>>>>>>> for
>>>>>>>>> users depending on a library that adheres to SemVer, to define a
>>>>>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it
>>>>>>>>> should
>>>>>>>>> not
>>>>>>>>> be as easy as that.
>>>>>>>>>
>>>>>>>>> Please consider fixing this soon.
>>>>>>>>>
>>>>>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira.
>>>>>>>>> The
>>>>>>>>> signup link on this page displays an error:
>>>>>>>>> http://maven.apache.org/users/
>>>>>>>>> **getting-help.html <http://maven.apache.org/****
>>>>>>>>> users/getting-help.html<http:/**/maven.apache.org/**users/**
>>>>>>>>> getting-help.html<http://maven.apache.org/**users/getting-help.html>
>>>>>>>>> >
>>>>>>>>> <http:/**/maven.apache.org/**users/**getting-help.html<http://maven.apache.org/users/**getting-help.html>
>>>>>>>>> <http**://maven.apache.org/users/**getting-help.html<http://maven.apache.org/users/getting-help.html>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this
>>>>>>>>> issue,
>>>>>>>>> but the initial report is for a similar issue, not this issue. The
>>>>>>>>> issue
>>>>>>>>> I
>>>>>>>>> describe above is reported and discussed in the comments for
>>>>>>>>> MNG-3092
>>>>>>>>> though.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jesse
>>>>>>>>>
>>>>>>>>> ------------------------------********------------------------**
>>>>>>>>> --**--**
>>>>>>>>> --**---------
>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@maven.******apac**he.org <http://apache.org><
>>>>>>>>> users-unsubscribe@**maven.**ap**ache.org <http://apache.org> <
>>>>>>>>> http://maven.apache.org><
>>>>>>>>>
>>>>>>>>> users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
>>>>>>>>> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>>>>> >
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>   ------------------------------******--------------------------**
>>>>>>>>> --**
>>>>>>>>>
>>>>>>>> --**
>>>>>>>>
>>>>>>>>  ---------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.****apac**he.org<
>>>>>>> http://apache.org**>
>>>>>>> <users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
>>>>>>> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>>> >
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>   ------------------------------******--------------------------**
>>>>>>> --**
>>>>>>>
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.****apac**he.org<
>>>>>> http://apache.org**>
>>>>>> <users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
>>>>>> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>> >
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>   ------------------------------******--------------------------**
>>>>>> --**
>>>>>>
>>>>> --**---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.****apac**he.org<
>>>>> http://apache.org**>
>>>>> <users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
>>>>> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>> >
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>>  ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>> <users-unsubscribe@**maven.apache.org<[hidden email]>
>>> >
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Baptiste MATHUS
In reply to this post by stephenconnolly
+1.
Version ranges are basically just a bad practice in my experience. I mostly
don't see any interest apart from being able to see a normally passing
build suddenly going rogue because you somehow had a dependency update
somewhere in the dependency tree. (I wrote something similar in that
comment
http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
)

So, please, Maven users, don't use them. It's like having scripts inside
your pom.xml, it might seem sexy and powerful, but it's dangerous.
Nail down a version, and upgrade explicitly when you need to and/or are
ready to. You'll be very happy that way and your build'll stay green.

Cheers

2012/9/28 Stephen Connolly <[hidden email]>

> Well that is a recipe for disaster. rules only make sense within the scope
> of the artifacts they apply to.
>
> This is kind of why version ranges are next to useless from a practical PoV
> anyway
>
> On 27 September 2012 23:05, Paul French <[hidden email]> wrote:
>
> > I would only want the same version rules applied to all artifacts, not on
> > a per artifact basis, that would be a nightmare! I understand that people
> > who produce artifacts have their own versioning rules. However we can
> take
> > that into account in our version ranging.
> >
> > Usually for 3rd party artifacts we have a very narrow version range since
> > we cannot trust the producer of that artifact not to break their current
> > API in later versions unless they support semantic versioning.
> >
> >
> > On 27/09/2012 22:29, Stephen Connolly wrote:
> >
> >> when is that class applied?
> >>
> >> each dependency would have its own comparator, as each dependency has
> its
> >> own versioning rules.
> >>
> >> and then don't start on epoch's (i.e. where the versioning rules change
> >> from under your feet mid sequence
> >>
> >> It's tempting... but dangerous... the closest I have come up with is the
> >> rulesets hack from versions-maven-plugin @ mojo... but even that has
> >> issues... hence why I haven't pushed it further.
> >>
> >> -Stephen
> >>
> >> On 27 September 2012 22:19, Paul French <[hidden email]> wrote:
> >>
> >>  Okay I see the problem.
> >>>
> >>> How about allowing a user to plugin a Version class that implements
> >>> Comparator
> >>>
> >>>    class MavenVersion implements Comparable<MavenVersion>
> >>>    {
> >>>      public int compareTo(MavenVersion o)
> >>>      {
> >>>        // your implementation
> >>>      }
> >>>    }
> >>>
> >>> Then we can all do whatever we need.
> >>>
> >>>
> >>> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
> >>>
> >>>  I understand that many people get caught
> >>>>
> >>>> But what do you expect from [1.7,1.8]?
> >>>> And [1.7,1.8-beta)?
> >>>>
> >>>> The actual semantic is pure mathematical range, including or excluding
> >>>> an
> >>>> extreme
> >>>>
> >>>> since 1.8-alpha<1.8-beta-<1.8-rc<1.****8-SNAPSHOT<1.8, it's pure math
> >>>>
> >>>> IMHO, anything that doesn't conform mathematical range will have some
> >>>> unexpected behaviour sometime
> >>>>
> >>>> Yes, people need to learn that they usually want
> >>>> [1.7,1.8-alpha-SNAPSHOT)
> >>>> if
> >>>> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
> >>>> Or we need to create another notation and define its semantics
> precisely
> >>>>
> >>>> Regards,
> >>>>
> >>>> Hervé
> >>>>
> >>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
> >>>>
> >>>>  +1
> >>>>>
> >>>>> I agree with Jesse.
> >>>>>
> >>>>> A version range like [1.7,1.8) should exclude any artifact that
> starts
> >>>>> with 1.8
> >>>>>
> >>>>> Then maven (or aether) would respect semantic versioning rules.
> >>>>>
> >>>>> We use version ranges/semantic versioning and API analysis to ensure
> >>>>> our
> >>>>> artifacts are versioned correctly. Sometimes we get caught out by
> what
> >>>>> Jesse outlined below.
> >>>>>
> >>>>> On 27/09/2012 15:51, Stephen Connolly wrote:
> >>>>>
> >>>>>  On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
> >>>>>>
> >>>>>>  Dear Maven Community,
> >>>>>>>
> >>>>>>> I am writing to beg you to fix the problems with the version ranges
> >>>>>>> in
> >>>>>>> Maven 3.0.5, specifically regarding the defining compatible version
> >>>>>>> ranges.
> >>>>>>>
> >>>>>>> I am using Maven 3.0.4. I have a simple project that depends on
> >>>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range
> as
> >>>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
> >>>>>>> define
> >>>>>>> the
> >>>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api
> version
> >>>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
> >>>>>>> slf4j-api
> >>>>>>> version 1.6.0-alpha2 is linked in.
> >>>>>>>
> >>>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then
> >>>>>>> the
> >>>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
> >>>>>>> released it would probably break again.
> >>>>>>>
> >>>>>>> This is all too counter-intuitive. The current version of SLF4J is
> >>>>>>> 1.7.1.
> >>>>>>> If my project was to be built against it, knowing that there is a
> >>>>>>> likelihood of an incompatible change being introduced in 1.8.0
> (SLF4J
> >>>>>>> does
> >>>>>>> not adhere to SemVer), I would like to define my version range for
> >>>>>>> slf4j-api as [1.7.0,1.8.0). I
> >>>>>>>
> >>>>>>>  I think you do [1.7.0,1.8.0-!)
> >>>>>>
> >>>>>> but that might just include 1.8.0-SNAPSHOT
> >>>>>>
> >>>>>>   have no way of knowing before the time what type of -RC0, -alpha2
> >>>>>>
> >>>>>>> qualified releases will be made for 1.8.0, so I can only exclude
> >>>>>>> 1.8.0.
> >>>>>>>
> >>>>>>> However, when 1.8.0-alpha2 is released with incompatible changes,
> my
> >>>>>>> build
> >>>>>>> will immediately be broken.
> >>>>>>>
> >>>>>>> I could depend on version 1.5.11 directly, without using a version
> >>>>>>> range,
> >>>>>>> but Maven considers this a soft version dependency and will ignore
> it
> >>>>>>> as
> >>>>>>> needed.
> >>>>>>>
> >>>>>>> It is apparent that there is no reliable way to define a
> >>>>>>> compatibility
> >>>>>>> range in Maven. I feel that this should be a major concern to all
> >>>>>>> Maven
> >>>>>>> users and developers.
> >>>>>>>
> >>>>>>> It would be a shame for all the effort made by the Maven community
> to
> >>>>>>> make
> >>>>>>> software builds stable and reproducible to be undermined by
> >>>>>>> consistent,
> >>>>>>> predictable breakage described above.
> >>>>>>>
> >>>>>>> I have read in mailing list archives that the suggested way of
> >>>>>>> excluding
> >>>>>>> all 1.8.0 pre-release version is to define an exclusive upper bound
> >>>>>>> as
> >>>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
> >>>>>>> with
> >>>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a
> >>>>>>> user
> >>>>>>> to
> >>>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
> >>>>>>>
> >>>>>>> My proposal is that the qualifier is ignored when comparing a
> version
> >>>>>>> to
> >>>>>>> the version number declared in an exclusive upper bound. ie.
> >>>>>>> 1.6.0-xyz
> >>>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
> >>>>>>> considered to fall outside of the version range. Importantly, it
> >>>>>>> should
> >>>>>>> only be for the special case of comparing to the version number in
> an
> >>>>>>> exclusive upper bound.
> >>>>>>>
> >>>>>>> If the powers that be see fit, an exception could be made for
> service
> >>>>>>> pack
> >>>>>>> qualifiers, which according to one web page on Maven version
> >>>>>>> ordering I
> >>>>>>> read, should be sorted after the release, although I would prefer
> to
> >>>>>>> see
> >>>>>>> Maven more closely aligned to SemVer, where all qualified version
> >>>>>>> numbers
> >>>>>>> are considered pre-release versions. I consider 1.7.2 a better
> >>>>>>> version
> >>>>>>> number than 1.7.1-sp1.
> >>>>>>>
> >>>>>>> Ultimately, I would like to be able to make things as easy as
> >>>>>>> possible
> >>>>>>> for
> >>>>>>> users depending on a library that adheres to SemVer, to define a
> >>>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it
> >>>>>>> should
> >>>>>>> not
> >>>>>>> be as easy as that.
> >>>>>>>
> >>>>>>> Please consider fixing this soon.
> >>>>>>>
> >>>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira.
> >>>>>>> The
> >>>>>>> signup link on this page displays an error:
> >>>>>>> http://maven.apache.org/users/
> >>>>>>> **getting-help.html <http://maven.apache.org/****
> >>>>>>> users/getting-help.html<
> http://maven.apache.org/**users/getting-help.html>
> >>>>>>> <http:/**/maven.apache.org/users/**getting-help.html<
> http://maven.apache.org/users/getting-help.html>
> >>>>>>> >
> >>>>>>>
> >>>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this
> >>>>>>> issue,
> >>>>>>> but the initial report is for a similar issue, not this issue. The
> >>>>>>> issue
> >>>>>>> I
> >>>>>>> describe above is reported and discussed in the comments for
> MNG-3092
> >>>>>>> though.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Jesse
> >>>>>>>
> >>>>>>>
> ------------------------------******--------------------------**--**
> >>>>>>> --**---------
> >>>>>>> To unsubscribe, e-mail:
> >>>>>>> users-unsubscribe@maven.****apac**he.org <http://apache.org><
> >>>>>>> users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
> >>>>>>> users-unsubscribe@**maven.apache.org<
> [hidden email]>
> >>>>>>> >
> >>>>>>>
> >>>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>>
> >>>>>>>  ------------------------------****----------------------------**
> >>>>>> --**
> >>>>>>
> >>>>> ---------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
> http://apache.org>
> >>>>> <users-unsubscribe@**maven.apache.org<
> [hidden email]>
> >>>>> >
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>  ------------------------------****----------------------------**
> >>>> --**---------
> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
> http://apache.org>
> >>>> <users-unsubscribe@**maven.apache.org<
> [hidden email]>
> >>>> >
> >>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>>>  ------------------------------****----------------------------**
> >>> --**---------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
> http://apache.org>
> >>> <users-unsubscribe@**maven.apache.org<
> [hidden email]>
> >>> >
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>>
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> [hidden email]>
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
> nbsp;!
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Ron Wheeler
+1
On 27/09/2012 7:20 PM, Baptiste MATHUS wrote:

> +1.
> Version ranges are basically just a bad practice in my experience. I mostly
> don't see any interest apart from being able to see a normally passing
> build suddenly going rogue because you somehow had a dependency update
> somewhere in the dependency tree. (I wrote something similar in that
> comment
> http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
> )
>
> So, please, Maven users, don't use them. It's like having scripts inside
> your pom.xml, it might seem sexy and powerful, but it's dangerous.
> Nail down a version, and upgrade explicitly when you need to and/or are
> ready to. You'll be very happy that way and your build'll stay green.
>
> Cheers
>
> 2012/9/28 Stephen Connolly <[hidden email]>
>
>> Well that is a recipe for disaster. rules only make sense within the scope
>> of the artifacts they apply to.
>>
>> This is kind of why version ranges are next to useless from a practical PoV
>> anyway
>>
>> On 27 September 2012 23:05, Paul French <[hidden email]> wrote:
>>
>>> I would only want the same version rules applied to all artifacts, not on
>>> a per artifact basis, that would be a nightmare! I understand that people
>>> who produce artifacts have their own versioning rules. However we can
>> take
>>> that into account in our version ranging.
>>>
>>> Usually for 3rd party artifacts we have a very narrow version range since
>>> we cannot trust the producer of that artifact not to break their current
>>> API in later versions unless they support semantic versioning.
>>>
>>>
>>> On 27/09/2012 22:29, Stephen Connolly wrote:
>>>
>>>> when is that class applied?
>>>>
>>>> each dependency would have its own comparator, as each dependency has
>> its
>>>> own versioning rules.
>>>>
>>>> and then don't start on epoch's (i.e. where the versioning rules change
>>>> from under your feet mid sequence
>>>>
>>>> It's tempting... but dangerous... the closest I have come up with is the
>>>> rulesets hack from versions-maven-plugin @ mojo... but even that has
>>>> issues... hence why I haven't pushed it further.
>>>>
>>>> -Stephen
>>>>
>>>> On 27 September 2012 22:19, Paul French <[hidden email]> wrote:
>>>>
>>>>   Okay I see the problem.
>>>>> How about allowing a user to plugin a Version class that implements
>>>>> Comparator
>>>>>
>>>>>     class MavenVersion implements Comparable<MavenVersion>
>>>>>     {
>>>>>       public int compareTo(MavenVersion o)
>>>>>       {
>>>>>         // your implementation
>>>>>       }
>>>>>     }
>>>>>
>>>>> Then we can all do whatever we need.
>>>>>
>>>>>
>>>>> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>>>>>
>>>>>   I understand that many people get caught
>>>>>> But what do you expect from [1.7,1.8]?
>>>>>> And [1.7,1.8-beta)?
>>>>>>
>>>>>> The actual semantic is pure mathematical range, including or excluding
>>>>>> an
>>>>>> extreme
>>>>>>
>>>>>> since 1.8-alpha<1.8-beta-<1.8-rc<1.****8-SNAPSHOT<1.8, it's pure math
>>>>>>
>>>>>> IMHO, anything that doesn't conform mathematical range will have some
>>>>>> unexpected behaviour sometime
>>>>>>
>>>>>> Yes, people need to learn that they usually want
>>>>>> [1.7,1.8-alpha-SNAPSHOT)
>>>>>> if
>>>>>> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
>>>>>> Or we need to create another notation and define its semantics
>> precisely
>>>>>> Regards,
>>>>>>
>>>>>> Hervé
>>>>>>
>>>>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
>>>>>>
>>>>>>   +1
>>>>>>> I agree with Jesse.
>>>>>>>
>>>>>>> A version range like [1.7,1.8) should exclude any artifact that
>> starts
>>>>>>> with 1.8
>>>>>>>
>>>>>>> Then maven (or aether) would respect semantic versioning rules.
>>>>>>>
>>>>>>> We use version ranges/semantic versioning and API analysis to ensure
>>>>>>> our
>>>>>>> artifacts are versioned correctly. Sometimes we get caught out by
>> what
>>>>>>> Jesse outlined below.
>>>>>>>
>>>>>>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>>>>>>
>>>>>>>   On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>>>>>>>>   Dear Maven Community,
>>>>>>>>> I am writing to beg you to fix the problems with the version ranges
>>>>>>>>> in
>>>>>>>>> Maven 3.0.5, specifically regarding the defining compatible version
>>>>>>>>> ranges.
>>>>>>>>>
>>>>>>>>> I am using Maven 3.0.4. I have a simple project that depends on
>>>>>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range
>> as
>>>>>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
>>>>>>>>> define
>>>>>>>>> the
>>>>>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api
>> version
>>>>>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
>>>>>>>>> slf4j-api
>>>>>>>>> version 1.6.0-alpha2 is linked in.
>>>>>>>>>
>>>>>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then
>>>>>>>>> the
>>>>>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>>>>>>>>> released it would probably break again.
>>>>>>>>>
>>>>>>>>> This is all too counter-intuitive. The current version of SLF4J is
>>>>>>>>> 1.7.1.
>>>>>>>>> If my project was to be built against it, knowing that there is a
>>>>>>>>> likelihood of an incompatible change being introduced in 1.8.0
>> (SLF4J
>>>>>>>>> does
>>>>>>>>> not adhere to SemVer), I would like to define my version range for
>>>>>>>>> slf4j-api as [1.7.0,1.8.0). I
>>>>>>>>>
>>>>>>>>>   I think you do [1.7.0,1.8.0-!)
>>>>>>>> but that might just include 1.8.0-SNAPSHOT
>>>>>>>>
>>>>>>>>    have no way of knowing before the time what type of -RC0, -alpha2
>>>>>>>>
>>>>>>>>> qualified releases will be made for 1.8.0, so I can only exclude
>>>>>>>>> 1.8.0.
>>>>>>>>>
>>>>>>>>> However, when 1.8.0-alpha2 is released with incompatible changes,
>> my
>>>>>>>>> build
>>>>>>>>> will immediately be broken.
>>>>>>>>>
>>>>>>>>> I could depend on version 1.5.11 directly, without using a version
>>>>>>>>> range,
>>>>>>>>> but Maven considers this a soft version dependency and will ignore
>> it
>>>>>>>>> as
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>>> It is apparent that there is no reliable way to define a
>>>>>>>>> compatibility
>>>>>>>>> range in Maven. I feel that this should be a major concern to all
>>>>>>>>> Maven
>>>>>>>>> users and developers.
>>>>>>>>>
>>>>>>>>> It would be a shame for all the effort made by the Maven community
>> to
>>>>>>>>> make
>>>>>>>>> software builds stable and reproducible to be undermined by
>>>>>>>>> consistent,
>>>>>>>>> predictable breakage described above.
>>>>>>>>>
>>>>>>>>> I have read in mailing list archives that the suggested way of
>>>>>>>>> excluding
>>>>>>>>> all 1.8.0 pre-release version is to define an exclusive upper bound
>>>>>>>>> as
>>>>>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
>>>>>>>>> with
>>>>>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a
>>>>>>>>> user
>>>>>>>>> to
>>>>>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>>>>>>>>
>>>>>>>>> My proposal is that the qualifier is ignored when comparing a
>> version
>>>>>>>>> to
>>>>>>>>> the version number declared in an exclusive upper bound. ie.
>>>>>>>>> 1.6.0-xyz
>>>>>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>>>>>>>>> considered to fall outside of the version range. Importantly, it
>>>>>>>>> should
>>>>>>>>> only be for the special case of comparing to the version number in
>> an
>>>>>>>>> exclusive upper bound.
>>>>>>>>>
>>>>>>>>> If the powers that be see fit, an exception could be made for
>> service
>>>>>>>>> pack
>>>>>>>>> qualifiers, which according to one web page on Maven version
>>>>>>>>> ordering I
>>>>>>>>> read, should be sorted after the release, although I would prefer
>> to
>>>>>>>>> see
>>>>>>>>> Maven more closely aligned to SemVer, where all qualified version
>>>>>>>>> numbers
>>>>>>>>> are considered pre-release versions. I consider 1.7.2 a better
>>>>>>>>> version
>>>>>>>>> number than 1.7.1-sp1.
>>>>>>>>>
>>>>>>>>> Ultimately, I would like to be able to make things as easy as
>>>>>>>>> possible
>>>>>>>>> for
>>>>>>>>> users depending on a library that adheres to SemVer, to define a
>>>>>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it
>>>>>>>>> should
>>>>>>>>> not
>>>>>>>>> be as easy as that.
>>>>>>>>>
>>>>>>>>> Please consider fixing this soon.
>>>>>>>>>
>>>>>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira.
>>>>>>>>> The
>>>>>>>>> signup link on this page displays an error:
>>>>>>>>> http://maven.apache.org/users/
>>>>>>>>> **getting-help.html <http://maven.apache.org/****
>>>>>>>>> users/getting-help.html<
>> http://maven.apache.org/**users/getting-help.html>
>>>>>>>>> <http:/**/maven.apache.org/users/**getting-help.html<
>> http://maven.apache.org/users/getting-help.html>
>>>>>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this
>>>>>>>>> issue,
>>>>>>>>> but the initial report is for a similar issue, not this issue. The
>>>>>>>>> issue
>>>>>>>>> I
>>>>>>>>> describe above is reported and discussed in the comments for
>> MNG-3092
>>>>>>>>> though.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jesse
>>>>>>>>>
>>>>>>>>>
>> ------------------------------******--------------------------**--**
>>>>>>>>> --**---------
>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@maven.****apac**he.org <http://apache.org><
>>>>>>>>> users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
>>>>>>>>> users-unsubscribe@**maven.apache.org<
>> [hidden email]>
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>   ------------------------------****----------------------------**
>>>>>>>> --**
>>>>>>>>
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
>> http://apache.org>
>>>>>>> <users-unsubscribe@**maven.apache.org<
>> [hidden email]>
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>   ------------------------------****----------------------------**
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
>> http://apache.org>
>>>>>> <users-unsubscribe@**maven.apache.org<
>> [hidden email]>
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>   ------------------------------****----------------------------**
>>>>> --**---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
>> http://apache.org>
>>>>> <users-unsubscribe@**maven.apache.org<
>> [hidden email]>
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
>> [hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>> --
>> Baptiste <Batmat> MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor !
>> nbsp;!
>>


--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Paul French
In reply to this post by Baptiste MATHUS
yes and no, depends....

We have a lot of developers and a lot of OSGi bundles. The public API of
each bundle is specified in the manifest. We use API analysis to compare
the latest code of the artifact with the last released version of that
artifact. So the version of the updated bundle is specified by api
analysis. As long as we have not broken backwards compatibility the
version goes up just a micro version. If the bundle's api is tested and
passes all its unit tests then it is released. All developers will get
the updated bundle without doing anything. If we have to break backwards
compatibilty then we go up a major version. No one will get this change
unless they want it by updating their version range in their POM. This
is good since the developer knows there is API changes and it is very
likely they will need to make changes in their code in how they use the
new API.

We do this in our sprint phases i.e. lots of developer activity working
on many different areas of many different products, no one needs to
touch their POM unless we agree to a major change (we avoid major
changes if possible)

When we create a release candidate of a particular product we generate
an effective POM where all exact versions of all artifacts are
specified. So yes we now use exact versions. We branch this single
effective POM to do release fixes and are happy to manually update the
POM since we expect the changes to be small.

Hence we can re-produce our releases anytime later.

I agree in general version ranges can cause problems. But in some
circumstances they can be useful.

On 28/09/2012 00:20, Baptiste MATHUS wrote:

> +1.
> Version ranges are basically just a bad practice in my experience. I mostly
> don't see any interest apart from being able to see a normally passing
> build suddenly going rogue because you somehow had a dependency update
> somewhere in the dependency tree. (I wrote something similar in that
> comment
> http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
> )
>
> So, please, Maven users, don't use them. It's like having scripts inside
> your pom.xml, it might seem sexy and powerful, but it's dangerous.
> Nail down a version, and upgrade explicitly when you need to and/or are
> ready to. You'll be very happy that way and your build'll stay green.
>
> Cheers
>
> 2012/9/28 Stephen Connolly <[hidden email]>
>
>> Well that is a recipe for disaster. rules only make sense within the scope
>> of the artifacts they apply to.
>>
>> This is kind of why version ranges are next to useless from a practical PoV
>> anyway
>>
>> On 27 September 2012 23:05, Paul French <[hidden email]> wrote:
>>
>>> I would only want the same version rules applied to all artifacts, not on
>>> a per artifact basis, that would be a nightmare! I understand that people
>>> who produce artifacts have their own versioning rules. However we can
>> take
>>> that into account in our version ranging.
>>>
>>> Usually for 3rd party artifacts we have a very narrow version range since
>>> we cannot trust the producer of that artifact not to break their current
>>> API in later versions unless they support semantic versioning.
>>>
>>>
>>> On 27/09/2012 22:29, Stephen Connolly wrote:
>>>
>>>> when is that class applied?
>>>>
>>>> each dependency would have its own comparator, as each dependency has
>> its
>>>> own versioning rules.
>>>>
>>>> and then don't start on epoch's (i.e. where the versioning rules change
>>>> from under your feet mid sequence
>>>>
>>>> It's tempting... but dangerous... the closest I have come up with is the
>>>> rulesets hack from versions-maven-plugin @ mojo... but even that has
>>>> issues... hence why I haven't pushed it further.
>>>>
>>>> -Stephen
>>>>
>>>> On 27 September 2012 22:19, Paul French <[hidden email]> wrote:
>>>>
>>>>   Okay I see the problem.
>>>>> How about allowing a user to plugin a Version class that implements
>>>>> Comparator
>>>>>
>>>>>     class MavenVersion implements Comparable<MavenVersion>
>>>>>     {
>>>>>       public int compareTo(MavenVersion o)
>>>>>       {
>>>>>         // your implementation
>>>>>       }
>>>>>     }
>>>>>
>>>>> Then we can all do whatever we need.
>>>>>
>>>>>
>>>>> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>>>>>
>>>>>   I understand that many people get caught
>>>>>> But what do you expect from [1.7,1.8]?
>>>>>> And [1.7,1.8-beta)?
>>>>>>
>>>>>> The actual semantic is pure mathematical range, including or excluding
>>>>>> an
>>>>>> extreme
>>>>>>
>>>>>> since 1.8-alpha<1.8-beta-<1.8-rc<1.****8-SNAPSHOT<1.8, it's pure math
>>>>>>
>>>>>> IMHO, anything that doesn't conform mathematical range will have some
>>>>>> unexpected behaviour sometime
>>>>>>
>>>>>> Yes, people need to learn that they usually want
>>>>>> [1.7,1.8-alpha-SNAPSHOT)
>>>>>> if
>>>>>> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
>>>>>> Or we need to create another notation and define its semantics
>> precisely
>>>>>> Regards,
>>>>>>
>>>>>> Hervé
>>>>>>
>>>>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
>>>>>>
>>>>>>   +1
>>>>>>> I agree with Jesse.
>>>>>>>
>>>>>>> A version range like [1.7,1.8) should exclude any artifact that
>> starts
>>>>>>> with 1.8
>>>>>>>
>>>>>>> Then maven (or aether) would respect semantic versioning rules.
>>>>>>>
>>>>>>> We use version ranges/semantic versioning and API analysis to ensure
>>>>>>> our
>>>>>>> artifacts are versioned correctly. Sometimes we get caught out by
>> what
>>>>>>> Jesse outlined below.
>>>>>>>
>>>>>>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>>>>>>
>>>>>>>   On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>>>>>>>>   Dear Maven Community,
>>>>>>>>> I am writing to beg you to fix the problems with the version ranges
>>>>>>>>> in
>>>>>>>>> Maven 3.0.5, specifically regarding the defining compatible version
>>>>>>>>> ranges.
>>>>>>>>>
>>>>>>>>> I am using Maven 3.0.4. I have a simple project that depends on
>>>>>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range
>> as
>>>>>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
>>>>>>>>> define
>>>>>>>>> the
>>>>>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api
>> version
>>>>>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
>>>>>>>>> slf4j-api
>>>>>>>>> version 1.6.0-alpha2 is linked in.
>>>>>>>>>
>>>>>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then
>>>>>>>>> the
>>>>>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>>>>>>>>> released it would probably break again.
>>>>>>>>>
>>>>>>>>> This is all too counter-intuitive. The current version of SLF4J is
>>>>>>>>> 1.7.1.
>>>>>>>>> If my project was to be built against it, knowing that there is a
>>>>>>>>> likelihood of an incompatible change being introduced in 1.8.0
>> (SLF4J
>>>>>>>>> does
>>>>>>>>> not adhere to SemVer), I would like to define my version range for
>>>>>>>>> slf4j-api as [1.7.0,1.8.0). I
>>>>>>>>>
>>>>>>>>>   I think you do [1.7.0,1.8.0-!)
>>>>>>>> but that might just include 1.8.0-SNAPSHOT
>>>>>>>>
>>>>>>>>    have no way of knowing before the time what type of -RC0, -alpha2
>>>>>>>>
>>>>>>>>> qualified releases will be made for 1.8.0, so I can only exclude
>>>>>>>>> 1.8.0.
>>>>>>>>>
>>>>>>>>> However, when 1.8.0-alpha2 is released with incompatible changes,
>> my
>>>>>>>>> build
>>>>>>>>> will immediately be broken.
>>>>>>>>>
>>>>>>>>> I could depend on version 1.5.11 directly, without using a version
>>>>>>>>> range,
>>>>>>>>> but Maven considers this a soft version dependency and will ignore
>> it
>>>>>>>>> as
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>>> It is apparent that there is no reliable way to define a
>>>>>>>>> compatibility
>>>>>>>>> range in Maven. I feel that this should be a major concern to all
>>>>>>>>> Maven
>>>>>>>>> users and developers.
>>>>>>>>>
>>>>>>>>> It would be a shame for all the effort made by the Maven community
>> to
>>>>>>>>> make
>>>>>>>>> software builds stable and reproducible to be undermined by
>>>>>>>>> consistent,
>>>>>>>>> predictable breakage described above.
>>>>>>>>>
>>>>>>>>> I have read in mailing list archives that the suggested way of
>>>>>>>>> excluding
>>>>>>>>> all 1.8.0 pre-release version is to define an exclusive upper bound
>>>>>>>>> as
>>>>>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
>>>>>>>>> with
>>>>>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a
>>>>>>>>> user
>>>>>>>>> to
>>>>>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>>>>>>>>
>>>>>>>>> My proposal is that the qualifier is ignored when comparing a
>> version
>>>>>>>>> to
>>>>>>>>> the version number declared in an exclusive upper bound. ie.
>>>>>>>>> 1.6.0-xyz
>>>>>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>>>>>>>>> considered to fall outside of the version range. Importantly, it
>>>>>>>>> should
>>>>>>>>> only be for the special case of comparing to the version number in
>> an
>>>>>>>>> exclusive upper bound.
>>>>>>>>>
>>>>>>>>> If the powers that be see fit, an exception could be made for
>> service
>>>>>>>>> pack
>>>>>>>>> qualifiers, which according to one web page on Maven version
>>>>>>>>> ordering I
>>>>>>>>> read, should be sorted after the release, although I would prefer
>> to
>>>>>>>>> see
>>>>>>>>> Maven more closely aligned to SemVer, where all qualified version
>>>>>>>>> numbers
>>>>>>>>> are considered pre-release versions. I consider 1.7.2 a better
>>>>>>>>> version
>>>>>>>>> number than 1.7.1-sp1.
>>>>>>>>>
>>>>>>>>> Ultimately, I would like to be able to make things as easy as
>>>>>>>>> possible
>>>>>>>>> for
>>>>>>>>> users depending on a library that adheres to SemVer, to define a
>>>>>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it
>>>>>>>>> should
>>>>>>>>> not
>>>>>>>>> be as easy as that.
>>>>>>>>>
>>>>>>>>> Please consider fixing this soon.
>>>>>>>>>
>>>>>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira.
>>>>>>>>> The
>>>>>>>>> signup link on this page displays an error:
>>>>>>>>> http://maven.apache.org/users/
>>>>>>>>> **getting-help.html <http://maven.apache.org/****
>>>>>>>>> users/getting-help.html<
>> http://maven.apache.org/**users/getting-help.html>
>>>>>>>>> <http:/**/maven.apache.org/users/**getting-help.html<
>> http://maven.apache.org/users/getting-help.html>
>>>>>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this
>>>>>>>>> issue,
>>>>>>>>> but the initial report is for a similar issue, not this issue. The
>>>>>>>>> issue
>>>>>>>>> I
>>>>>>>>> describe above is reported and discussed in the comments for
>> MNG-3092
>>>>>>>>> though.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jesse
>>>>>>>>>
>>>>>>>>>
>> ------------------------------******--------------------------**--**
>>>>>>>>> --**---------
>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>> users-unsubscribe@maven.****apac**he.org <http://apache.org><
>>>>>>>>> users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
>>>>>>>>> users-unsubscribe@**maven.apache.org<
>> [hidden email]>
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>   ------------------------------****----------------------------**
>>>>>>>> --**
>>>>>>>>
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
>> http://apache.org>
>>>>>>> <users-unsubscribe@**maven.apache.org<
>> [hidden email]>
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>   ------------------------------****----------------------------**
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
>> http://apache.org>
>>>>>> <users-unsubscribe@**maven.apache.org<
>> [hidden email]>
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>   ------------------------------****----------------------------**
>>>>> --**---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
>> http://apache.org>
>>>>> <users-unsubscribe@**maven.apache.org<
>> [hidden email]>
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
>> [hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>> --
>> Baptiste <Batmat> MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor !
>> nbsp;!
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Jesse Long
In reply to this post by Baptiste MATHUS
Without version ranges, how do I write a library that works with SLF4J
version 1.5.*, but does not work with SLF4J 1.6.*?

Do I depend on, say, version 1.5.11? Then when a user depends on my
library, and on slf4j-api directly, specifying slf4j-api version 1.6.0
in his pom, Maven will link in 1.6.0. So that is pretty useless to me.
If I find a way to enforce version 1.5.11. Then I am loosing the ability
to upgrade to any future version 1.5.*.

Cheers,
Jesse

On 28/09/2012 01:20, Baptiste MATHUS wrote:

> +1.
> Version ranges are basically just a bad practice in my experience. I mostly
> don't see any interest apart from being able to see a normally passing
> build suddenly going rogue because you somehow had a dependency update
> somewhere in the dependency tree. (I wrote something similar in that
> comment
> http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
> )
>
> So, please, Maven users, don't use them. It's like having scripts inside
> your pom.xml, it might seem sexy and powerful, but it's dangerous.
> Nail down a version, and upgrade explicitly when you need to and/or are
> ready to. You'll be very happy that way and your build'll stay green.
>
> Cheers
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Jesse Long
In reply to this post by Hervé BOUTEMY
My point is really about exclusive upper bounds.

I expect that [1.7,1.8] should contains 1.7.0 and above (no snapshots
and prerelease for 1.7.0) and 1.8.* release versions. Having said that,
I dont really care too much about this use case and have not thought
much about it. I have thought about exclusive upper bounds, and I think
my proposal is the best solution.

[1.7,1.8-beta): Like I said, there is no sense in that at all. Why would
a developer want to include 1.8-alpha, but not 1.8-beta? Indeed, why
would he want 1.8.0-alpha4 and not 1.8.0? I think we should not make the
majority of use cases, where the exclusive upper bound defines a
compatibility break according to semver, to suffer because some users
will do weird things like [1.7,1.8-beta).

[1.7,1.8-beta) is a valid input however, so we should make a plan for
it. We could just say that if the upper bound has a qualifier, compare
as per usual. If the exclusive upper bound has no qualifier, then ignore
the qualifier of the version being compared to the upper bound. So, in
[1.7.0,1.8.0), 1.8.0 is outside the range and so is 1.8.0-alpha1. In
[1.7.0,1.8.0-beta) 1.8.0 is outside the range, 1.8.0-beta3 is outside
the range and 1.8.0-alpha4 is inside the range.

Regarding mathematics. It might help to think this problem as a mismatch
of data types. I am defining my range in integers, and I am getting
screwed by the fractions.

Consider that 1.8.0 is an integer, lets write it as 180. The next
integer is 1.8.1 - 181. 1.8.1-alpha4 decimal, lets write it as 181.04.
But because qualified version numbers are PRE release, the 181.04 comes
before 181. The sequence is like: 180.01, 180.02, 180.21, 180, 181.04,
181.05, 181.06, 181.33, 181.

I am defining my version range [1.7.0,1.8.0) in integers, but maven find
a decimal (float) within the range. I am asking that when I define my
range as an integer, that Maven does that Java does when casting a float
to an integer, and remove the parts after the decimal point. So my range
is [170,180). ((int)180.04f) == 180 so it is outside of the range. If I
cared about the fractions I would include them in the upper bound, and
you would not need to cast the version number to an integer.

Again, only for exclusive upper bounds where it makes sense (I have not
thought about other use cases, but by limiting it to exclusive upper
bounds, you solve my problem and dont change any other behavior).

Cheers,
Jesse

On 27/09/2012 22:40, Hervé BOUTEMY wrote:

> I understand that many people get caught
>
> But what do you expect from [1.7,1.8]?
> And [1.7,1.8-beta)?
>
> The actual semantic is pure mathematical range, including or excluding an
> extreme
>
> since 1.8-alpha<1.8-beta-<1.8-rc<1.8-SNAPSHOT<1.8, it's pure math
> IMHO, anything that doesn't conform mathematical range will have some
> unexpected behaviour sometime
>
> Yes, people need to learn that they usually want [1.7,1.8-alpha-SNAPSHOT) if
> they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
> Or we need to create another notation and define its semantics precisely
>
> Regards,
>
> Hervé
>
> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
>> +1
>>
>> I agree with Jesse.
>>
>> A version range like [1.7,1.8) should exclude any artifact that starts
>> with 1.8
>>
>> Then maven (or aether) would respect semantic versioning rules.
>>
>> We use version ranges/semantic versioning and API analysis to ensure our
>> artifacts are versioned correctly. Sometimes we get caught out by what
>> Jesse outlined below.
>>
>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>> On 27 September 2012 14:41, Jesse Long <[hidden email]> wrote:
>>>> Dear Maven Community,
>>>>
>>>> I am writing to beg you to fix the problems with the version ranges in
>>>> Maven 3.0.5, specifically regarding the defining compatible version
>>>> ranges.
>>>>
>>>> I am using Maven 3.0.4. I have a simple project that depends on
>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define
>>>> the
>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
>>>> version 1.6.0-alpha2 is linked in.
>>>>
>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
>>>> released it would probably break again.
>>>>
>>>> This is all too counter-intuitive. The current version of SLF4J is 1.7.1.
>>>> If my project was to be built against it, knowing that there is a
>>>> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
>>>> does
>>>> not adhere to SemVer), I would like to define my version range for
>>>> slf4j-api as [1.7.0,1.8.0). I
>>> I think you do [1.7.0,1.8.0-!)
>>>
>>> but that might just include 1.8.0-SNAPSHOT
>>>
>>>> have no way of knowing before the time what type of -RC0, -alpha2
>>>> qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.
>>>>
>>>> However, when 1.8.0-alpha2 is released with incompatible changes, my
>>>> build
>>>> will immediately be broken.
>>>>
>>>> I could depend on version 1.5.11 directly, without using a version range,
>>>> but Maven considers this a soft version dependency and will ignore it as
>>>> needed.
>>>>
>>>> It is apparent that there is no reliable way to define a compatibility
>>>> range in Maven. I feel that this should be a major concern to all Maven
>>>> users and developers.
>>>>
>>>> It would be a shame for all the effort made by the Maven community to
>>>> make
>>>> software builds stable and reproducible to be undermined by consistent,
>>>> predictable breakage described above.
>>>>
>>>> I have read in mailing list archives that the suggested way of excluding
>>>> all 1.8.0 pre-release version is to define an exclusive upper bound as
>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with
>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a user
>>>> to
>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
>>>>
>>>> My proposal is that the qualifier is ignored when comparing a version to
>>>> the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
>>>> considered to fall outside of the version range. Importantly, it should
>>>> only be for the special case of comparing to the version number in an
>>>> exclusive upper bound.
>>>>
>>>> If the powers that be see fit, an exception could be made for service
>>>> pack
>>>> qualifiers, which according to one web page on Maven version ordering I
>>>> read, should be sorted after the release, although I would prefer to see
>>>> Maven more closely aligned to SemVer, where all qualified version numbers
>>>> are considered pre-release versions. I consider 1.7.2 a better version
>>>> number than 1.7.1-sp1.
>>>>
>>>> Ultimately, I would like to be able to make things as easy as possible
>>>> for
>>>> users depending on a library that adheres to SemVer, to define a
>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it should
>>>> not
>>>> be as easy as that.
>>>>
>>>> Please consider fixing this soon.
>>>>
>>>> I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
>>>> signup link on this page displays an error:
>>>> http://maven.apache.org/users/
>>>> **getting-help.html <http://maven.apache.org/users/getting-help.html>
>>>>
>>>> Jira issue MNG-3092, reported over 5 years ago, is related to this issue,
>>>> but the initial report is for a similar issue, not this issue. The issue
>>>> I
>>>> describe above is reported and discussed in the comments for MNG-3092
>>>> though.
>>>>
>>>> Thanks,
>>>> Jesse
>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail:
>>>> users-unsubscribe@maven.**apache.org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Mark Struberg
In reply to this post by stephenconnolly
Sad but true.

An example:

There are projects which use "1.0-MR1" as "Milestone Release"

which gets released _before_ 1.0 final.

And there are other projects which use "1.0-MR1" as "Maintenance Release"

which obviously gets released _after_ 1.0 final.

Anything else than pure numbers is a candidate to be broken somehow.


LieGrue,
strub

----- Original Message -----

> From: Stephen Connolly <[hidden email]>
> To: Maven Users List <[hidden email]>
> Cc:
> Sent: Friday, September 28, 2012 1:03 AM
> Subject: Re: Version ranges not working
>
> My experience with versions-maven-plugin would show different, but each to
> their own
>
> On 27 September 2012 23:56, Paul French <[hidden email]> wrote:
>
>>  I have to disagree. Version ranges are very useful to us especially with
>>  artifacts we control where we use semantic versioning and api analysis to
>>  enforce this.
>>
>>  Artifacts we don't control the versioning of e.g SLF4J we nail down the
>>  version we use.
>>
>>  Our product POM's can have 100's of version ranged artifacts
>>
>>  If we could plugin a version range class into maven (maven would ship with
>>  a version range class with the rules it uses now), at least I would then
>>  have a choice to replace it with an implementation I'm happier with.
>>
>>  Anyway it works for us as it is now, so I'm not going to lose any sleep
>>  over it.
>>
>>  Cheers
>>
>>
>>  On 27/09/2012 23:36, Stephen Connolly wrote:
>>
>>>  Well that is a recipe for disaster. rules only make sense within the
> scope
>>>  of the artifacts they apply to.
>>>
>>>  This is kind of why version ranges are next to useless from a practical
>>>  PoV
>>>  anyway
>>>
>>>  On 27 September 2012 23:05, Paul French <[hidden email]>
> wrote:
>>>
>>>   I would only want the same version rules applied to all artifacts, not
> on
>>>>  a per artifact basis, that would be a nightmare! I understand that
> people
>>>>  who produce artifacts have their own versioning rules. However we
> can
>>>>  take
>>>>  that into account in our version ranging.
>>>>
>>>>  Usually for 3rd party artifacts we have a very narrow version range
> since
>>>>  we cannot trust the producer of that artifact not to break their
> current
>>>>  API in later versions unless they support semantic versioning.
>>>>
>>>>
>>>>  On 27/09/2012 22:29, Stephen Connolly wrote:
>>>>
>>>>   when is that class applied?
>>>>>
>>>>>  each dependency would have its own comparator, as each
> dependency has
>>>>>  its
>>>>>  own versioning rules.
>>>>>
>>>>>  and then don't start on epoch's (i.e. where the
> versioning rules change
>>>>>  from under your feet mid sequence
>>>>>
>>>>>  It's tempting... but dangerous... the closest I have come
> up with is the
>>>>>  rulesets hack from versions-maven-plugin @ mojo... but even
> that has
>>>>>  issues... hence why I haven't pushed it further.
>>>>>
>>>>>  -Stephen
>>>>>
>>>>>  On 27 September 2012 22:19, Paul French
> <[hidden email]> wrote:
>>>>>
>>>>>    Okay I see the problem.
>>>>>
>>>>>>  How about allowing a user to plugin a Version class that
> implements
>>>>>>  Comparator
>>>>>>
>>>>>>      class MavenVersion implements
> Comparable<MavenVersion>
>>>>>>      {
>>>>>>        public int compareTo(MavenVersion o)
>>>>>>        {
>>>>>>          // your implementation
>>>>>>        }
>>>>>>      }
>>>>>>
>>>>>>  Then we can all do whatever we need.
>>>>>>
>>>>>>
>>>>>>  On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>>>>>>
>>>>>>    I understand that many people get caught
>>>>>>
>>>>>>>  But what do you expect from [1.7,1.8]?
>>>>>>>  And [1.7,1.8-beta)?
>>>>>>>
>>>>>>>  The actual semantic is pure mathematical range,
> including or excluding
>>>>>>>  an
>>>>>>>  extreme
>>>>>>>
>>>>>>>  since
> 1.8-alpha<1.8-beta-<1.8-rc<1.******8-SNAPSHOT<1.8, it's pure
>>>>>>>  math
>>>>>>>
>>>>>>>
>>>>>>>  IMHO, anything that doesn't conform mathematical
> range will have some
>>>>>>>  unexpected behaviour sometime
>>>>>>>
>>>>>>>  Yes, people need to learn that they usually want
>>>>>>>  [1.7,1.8-alpha-SNAPSHOT)
>>>>>>>  if
>>>>>>>  they want to be precise. Or approximations:
> [1.7,1.8-a), [1.7,1.7.999]
>>>>>>>  Or we need to create another notation and define its
> semantics
>>>>>>>  precisely
>>>>>>>
>>>>>>>  Regards,
>>>>>>>
>>>>>>>  Hervé
>>>>>>>
>>>>>>>  Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit
> :
>>>>>>>
>>>>>>>    +1
>>>>>>>
>>>>>>>>  I agree with Jesse.
>>>>>>>>
>>>>>>>>  A version range like [1.7,1.8) should exclude any
> artifact that
>>>>>>>>  starts
>>>>>>>>  with 1.8
>>>>>>>>
>>>>>>>>  Then maven (or aether) would respect semantic
> versioning rules.
>>>>>>>>
>>>>>>>>  We use version ranges/semantic versioning and API
> analysis to ensure
>>>>>>>>  our
>>>>>>>>  artifacts are versioned correctly. Sometimes we get
> caught out by
>>>>>>>>  what
>>>>>>>>  Jesse outlined below.
>>>>>>>>
>>>>>>>>  On 27/09/2012 15:51, Stephen Connolly wrote:
>>>>>>>>
>>>>>>>>    On 27 September 2012 14:41, Jesse Long
> <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>>    Dear Maven Community,
>>>>>>>>>
>>>>>>>>>>  I am writing to beg you to fix the problems
> with the version ranges
>>>>>>>>>>  in
>>>>>>>>>>  Maven 3.0.5, specifically regarding the
> defining compatible version
>>>>>>>>>>  ranges.
>>>>>>>>>>
>>>>>>>>>>  I am using Maven 3.0.4. I have a simple
> project that depends on
>>>>>>>>>>  org.slf4j:slf4j-api version 1.5.*. I define
> my compatibility range
>>>>>>>>>>  as
>>>>>>>>>>  [1.5.0,1.6.0), but this links slf4j-api
> version 1.6.0-RC0. If I
>>>>>>>>>>  define
>>>>>>>>>>  the
>>>>>>>>>>  version range as [1.5.0,1.6.0-SNAPSHOT) I
> still get slf4j-api
>>>>>>>>>>  version
>>>>>>>>>>  1.6.0-RC0 linked in. I then tried
> [1.5.0,1.6.0-RC0), but then
>>>>>>>>>>  slf4j-api
>>>>>>>>>>  version 1.6.0-alpha2 is linked in.
>>>>>>>>>>
>>>>>>>>>>  Eventually, I discover that if I ask for
> [1.5.0,1.6.0-alpha), then
>>>>>>>>>>  the
>>>>>>>>>>  correct version, 1.5.11, is linked in. But
> if version 1.6.0-aa7 was
>>>>>>>>>>  released it would probably break again.
>>>>>>>>>>
>>>>>>>>>>  This is all too counter-intuitive. The
> current version of SLF4J is
>>>>>>>>>>  1.7.1.
>>>>>>>>>>  If my project was to be built against it,
> knowing that there is a
>>>>>>>>>>  likelihood of an incompatible change being
> introduced in 1.8.0
>>>>>>>>>>  (SLF4J
>>>>>>>>>>  does
>>>>>>>>>>  not adhere to SemVer), I would like to
> define my version range for
>>>>>>>>>>  slf4j-api as [1.7.0,1.8.0). I
>>>>>>>>>>
>>>>>>>>>>    I think you do [1.7.0,1.8.0-!)
>>>>>>>>>>
>>>>>>>>>  but that might just include 1.8.0-SNAPSHOT
>>>>>>>>>
>>>>>>>>>     have no way of knowing before the time what
> type of -RC0, -alpha2
>>>>>>>>>
>>>>>>>>>   qualified releases will be made for 1.8.0, so
> I can only exclude
>>>>>>>>>>  1.8.0.
>>>>>>>>>>
>>>>>>>>>>  However, when 1.8.0-alpha2 is released with
> incompatible changes,
>>>>>>>>>>  my
>>>>>>>>>>  build
>>>>>>>>>>  will immediately be broken.
>>>>>>>>>>
>>>>>>>>>>  I could depend on version 1.5.11 directly,
> without using a version
>>>>>>>>>>  range,
>>>>>>>>>>  but Maven considers this a soft version
> dependency and will ignore
>>>>>>>>>>  it
>>>>>>>>>>  as
>>>>>>>>>>  needed.
>>>>>>>>>>
>>>>>>>>>>  It is apparent that there is no reliable
> way to define a
>>>>>>>>>>  compatibility
>>>>>>>>>>  range in Maven. I feel that this should be
> a major concern to all
>>>>>>>>>>  Maven
>>>>>>>>>>  users and developers.
>>>>>>>>>>
>>>>>>>>>>  It would be a shame for all the effort made
> by the Maven community
>>>>>>>>>>  to
>>>>>>>>>>  make
>>>>>>>>>>  software builds stable and reproducible to
> be undermined by
>>>>>>>>>>  consistent,
>>>>>>>>>>  predictable breakage described above.
>>>>>>>>>>
>>>>>>>>>>  I have read in mailing list archives that
> the suggested way of
>>>>>>>>>>  excluding
>>>>>>>>>>  all 1.8.0 pre-release version is to define
> an exclusive upper bound
>>>>>>>>>>  as
>>>>>>>>>>  1.8.0-SNAPSHOT - like
> [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
>>>>>>>>>>  with
>>>>>>>>>>  1.6.0-RC0, this does not work. Also, it
> makes no sense at all for a
>>>>>>>>>>  user
>>>>>>>>>>  to
>>>>>>>>>>  wish to include 1.8.0-SNAPSHOT and not
> 1.8.0.
>>>>>>>>>>
>>>>>>>>>>  My proposal is that the qualifier is
> ignored when comparing a
>>>>>>>>>>  version
>>>>>>>>>>  to
>>>>>>>>>>  the version number declared in an exclusive
> upper bound. ie.
>>>>>>>>>>  1.6.0-xyz
>>>>>>>>>>  should be considered equal to 1.6.0 in
> [1.5.0,1.6.0), and therefore
>>>>>>>>>>  considered to fall outside of the version
> range. Importantly, it
>>>>>>>>>>  should
>>>>>>>>>>  only be for the special case of comparing
> to the version number in
>>>>>>>>>>  an
>>>>>>>>>>  exclusive upper bound.
>>>>>>>>>>
>>>>>>>>>>  If the powers that be see fit, an exception
> could be made for
>>>>>>>>>>  service
>>>>>>>>>>  pack
>>>>>>>>>>  qualifiers, which according to one web page
> on Maven version
>>>>>>>>>>  ordering I
>>>>>>>>>>  read, should be sorted after the release,
> although I would prefer
>>>>>>>>>>  to
>>>>>>>>>>  see
>>>>>>>>>>  Maven more closely aligned to SemVer, where
> all qualified version
>>>>>>>>>>  numbers
>>>>>>>>>>  are considered pre-release versions. I
> consider 1.7.2 a better
>>>>>>>>>>  version
>>>>>>>>>>  number than 1.7.1-sp1.
>>>>>>>>>>
>>>>>>>>>>  Ultimately, I would like to be able to make
> things as easy as
>>>>>>>>>>  possible
>>>>>>>>>>  for
>>>>>>>>>>  users depending on a library that adheres
> to SemVer, to define a
>>>>>>>>>>  compatibility range like: [1.4.0,2.0.0). I
> see no reason why it
>>>>>>>>>>  should
>>>>>>>>>>  not
>>>>>>>>>>  be as easy as that.
>>>>>>>>>>
>>>>>>>>>>  Please consider fixing this soon.
>>>>>>>>>>
>>>>>>>>>>  I have not logged a Jira issue, as I cannot
> log into CodeHaus Jira.
>>>>>>>>>>  The
>>>>>>>>>>  signup link on this page displays an error:
>>>>>>>>>>  http://maven.apache.org/users/
>>>>>>>>>>  **getting-help.html
> <http://maven.apache.org/****
>>>>>>>>>>
> users/getting-help.html<http:/**/maven.apache.org/**users/**
>>>>>>>>>>
> getting-help.html<http://maven.apache.org/**users/getting-help.html>
>>>>>>>>>>  >
>>>>>>>>>>
> <http:/**/maven.apache.org/**users/**getting-help.html<http://maven.apache.org/users/**getting-help.html>
>>>>>>>>>>
> <http**://maven.apache.org/users/**getting-help.html<http://maven.apache.org/users/getting-help.html>
>>>>>>>>>>  >
>>>>>>>>>>
>>>>>>>>>>  Jira issue MNG-3092, reported over 5 years
> ago, is related to this
>>>>>>>>>>  issue,
>>>>>>>>>>  but the initial report is for a similar
> issue, not this issue. The
>>>>>>>>>>  issue
>>>>>>>>>>  I
>>>>>>>>>>  describe above is reported and discussed in
> the comments for
>>>>>>>>>>  MNG-3092
>>>>>>>>>>  though.
>>>>>>>>>>
>>>>>>>>>>  Thanks,
>>>>>>>>>>  Jesse
>>>>>>>>>>
>>>>>>>>>>
> ------------------------------********------------------------**
>>>>>>>>>>  --**--**
>>>>>>>>>>  --**---------
>>>>>>>>>>  To unsubscribe, e-mail:
>>>>>>>>>>  users-unsubscribe@maven.******apac**he.org
> <http://apache.org><
>>>>>>>>>>  users-unsubscribe@**maven.**ap**ache.org
> <http://apache.org> <
>>>>>>>>>>  http://maven.apache.org><
>>>>>>>>>>
>>>>>>>>>>  users-unsubscribe@**maven.**apache.org
> <http://maven.apache.org><
>>>>>>>>>>
> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>>>>>>  >
>>>>>>>>>>  For additional commands, e-mail:
> [hidden email]
>>>>>>>>>>
>>>>>>>>>>  
> ------------------------------******--------------------------**
>>>>>>>>>>  --**
>>>>>>>>>>
>>>>>>>>>  --**
>>>>>>>>>
>>>>>>>>>   ---------
>>>>>>>>  To unsubscribe, e-mail:
> users-unsubscribe@maven.****apac**he.org<
>>>>>>>>  http://apache.org**>
>>>>>>>>  <users-unsubscribe@**maven.**apache.org
> <http://maven.apache.org><
>>>>>>>>
> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>>>>  >
>>>>>>>>  For additional commands, e-mail:
> [hidden email]
>>>>>>>>
>>>>>>>>  
> ------------------------------******--------------------------**
>>>>>>>>  --**
>>>>>>>>
>>>>>>>  --**---------
>>>>>>>  To unsubscribe, e-mail:
> users-unsubscribe@maven.****apac**he.org<
>>>>>>>  http://apache.org**>
>>>>>>>  <users-unsubscribe@**maven.**apache.org
> <http://maven.apache.org><
>>>>>>>
> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>>>  >
>>>>>>>  For additional commands, e-mail:
> [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>  
> ------------------------------******--------------------------**
>>>>>>>  --**
>>>>>>>
>>>>>>  --**---------
>>>>>>  To unsubscribe, e-mail:
> users-unsubscribe@maven.****apac**he.org<
>>>>>>  http://apache.org**>
>>>>>>  <users-unsubscribe@**maven.**apache.org
> <http://maven.apache.org><
>>>>>>
> users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>>>  >
>>>>>>  For additional commands, e-mail:
> [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>>  
> ------------------------------****----------------------------**
>>>>  --**---------
>>>>  To unsubscribe, e-mail:
> users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>>
> <users-unsubscribe@**maven.apache.org<[hidden email]>
>>>>  >
>>>>  For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>
>>  ------------------------------**------------------------------**---------
>>  To unsubscribe, e-mail:
> users-unsubscribe@maven.**apache.org<[hidden email]>
>>  For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Michael McCallum-5
In reply to this post by stephenconnolly
For a practical solution...

I just stopped using 0's in versions.. maven interprets 1.8 as 1.8.0
then [1.7,1.8) will never match 1.8.1-SNAPSHOT

invariably you don't actually want a third parties release to affect you
build because what they consider and breaking change might not be for you
therefore you need your own lifecyle for the external dependency. I use
composition poms for slf4j it looks like this...

http://search.maven.org/remotecontent?filepath=net/stickycode/composite/sticky-composite-logging-api/2.1/sticky-composite-logging-api-2.1.pom

All my projects depend on the composite at [2,3) and as I control the
lifecycle it always works. I can upgrade the version across all my projects
with a new release of the composite.

You may note the two point version... personally I don't bother with the
patch version, two points is enough, if you break it change the major
version and if you don't change the minor.

my 2c

Michael
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version ranges not working

Michael McCallum-5
In reply to this post by Baptiste MATHUS
I - almost - disagree completely, I've successfully used ranges on seven
separate commercial projects. A mix of sizes from corporate to startup.

If you care at all about agility being explicit everyone is very
cumbersome, the fundamental aspect is determinism - meaning that its
obvious WHY it behaves the way it does, once you understand how maven
implements ranges its very easy to use to them to great effect.

Having said that using ranges can be dangerous hence the composition
pattern mentioned in my previous email.

When you say nail down your version do you use [1.7.1] or 1.7.1?

On Fri, Sep 28, 2012 at 11:20 AM, Baptiste MATHUS <[hidden email]> wrote:

> +1.
> Version ranges are basically just a bad practice in my experience. I mostly
> don't see any interest apart from being able to see a normally passing
> build suddenly going rogue because you somehow had a dependency update
> somewhere in the dependency tree. (I wrote something similar in that
> comment
>
> http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
> )
>
> So, please, Maven users, don't use them. It's like having scripts inside
> your pom.xml, it might seem sexy and powerful, but it's dangerous.
> Nail down a version, and upgrade explicitly when you need to and/or are
> ready to. You'll be very happy that way and your build'll stay green.
>
> Cheers
>
> 2012/9/28 Stephen Connolly <[hidden email]>
>
> > Well that is a recipe for disaster. rules only make sense within the
> scope
> > of the artifacts they apply to.
> >
> > This is kind of why version ranges are next to useless from a practical
> PoV
> > anyway
> >
> > On 27 September 2012 23:05, Paul French <[hidden email]> wrote:
> >
> > > I would only want the same version rules applied to all artifacts, not
> on
> > > a per artifact basis, that would be a nightmare! I understand that
> people
> > > who produce artifacts have their own versioning rules. However we can
> > take
> > > that into account in our version ranging.
> > >
> > > Usually for 3rd party artifacts we have a very narrow version range
> since
> > > we cannot trust the producer of that artifact not to break their
> current
> > > API in later versions unless they support semantic versioning.
> > >
> > >
> > > On 27/09/2012 22:29, Stephen Connolly wrote:
> > >
> > >> when is that class applied?
> > >>
> > >> each dependency would have its own comparator, as each dependency has
> > its
> > >> own versioning rules.
> > >>
> > >> and then don't start on epoch's (i.e. where the versioning rules
> change
> > >> from under your feet mid sequence
> > >>
> > >> It's tempting... but dangerous... the closest I have come up with is
> the
> > >> rulesets hack from versions-maven-plugin @ mojo... but even that has
> > >> issues... hence why I haven't pushed it further.
> > >>
> > >> -Stephen
> > >>
> > >> On 27 September 2012 22:19, Paul French <[hidden email]>
> wrote:
> > >>
> > >>  Okay I see the problem.
> > >>>
> > >>> How about allowing a user to plugin a Version class that implements
> > >>> Comparator
> > >>>
> > >>>    class MavenVersion implements Comparable<MavenVersion>
> > >>>    {
> > >>>      public int compareTo(MavenVersion o)
> > >>>      {
> > >>>        // your implementation
> > >>>      }
> > >>>    }
> > >>>
> > >>> Then we can all do whatever we need.
> > >>>
> > >>>
> > >>> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
> > >>>
> > >>>  I understand that many people get caught
> > >>>>
> > >>>> But what do you expect from [1.7,1.8]?
> > >>>> And [1.7,1.8-beta)?
> > >>>>
> > >>>> The actual semantic is pure mathematical range, including or
> excluding
> > >>>> an
> > >>>> extreme
> > >>>>
> > >>>> since 1.8-alpha<1.8-beta-<1.8-rc<1.****8-SNAPSHOT<1.8, it's pure
> math
> > >>>>
> > >>>> IMHO, anything that doesn't conform mathematical range will have
> some
> > >>>> unexpected behaviour sometime
> > >>>>
> > >>>> Yes, people need to learn that they usually want
> > >>>> [1.7,1.8-alpha-SNAPSHOT)
> > >>>> if
> > >>>> they want to be precise. Or approximations: [1.7,1.8-a),
> [1.7,1.7.999]
> > >>>> Or we need to create another notation and define its semantics
> > precisely
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>> Hervé
> > >>>>
> > >>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
> > >>>>
> > >>>>  +1
> > >>>>>
> > >>>>> I agree with Jesse.
> > >>>>>
> > >>>>> A version range like [1.7,1.8) should exclude any artifact that
> > starts
> > >>>>> with 1.8
> > >>>>>
> > >>>>> Then maven (or aether) would respect semantic versioning rules.
> > >>>>>
> > >>>>> We use version ranges/semantic versioning and API analysis to
> ensure
> > >>>>> our
> > >>>>> artifacts are versioned correctly. Sometimes we get caught out by
> > what
> > >>>>> Jesse outlined below.
> > >>>>>
> > >>>>> On 27/09/2012 15:51, Stephen Connolly wrote:
> > >>>>>
> > >>>>>  On 27 September 2012 14:41, Jesse Long <[hidden email]>
> wrote:
> > >>>>>>
> > >>>>>>  Dear Maven Community,
> > >>>>>>>
> > >>>>>>> I am writing to beg you to fix the problems with the version
> ranges
> > >>>>>>> in
> > >>>>>>> Maven 3.0.5, specifically regarding the defining compatible
> version
> > >>>>>>> ranges.
> > >>>>>>>
> > >>>>>>> I am using Maven 3.0.4. I have a simple project that depends on
> > >>>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility
> range
> > as
> > >>>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
> > >>>>>>> define
> > >>>>>>> the
> > >>>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api
> > version
> > >>>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
> > >>>>>>> slf4j-api
> > >>>>>>> version 1.6.0-alpha2 is linked in.
> > >>>>>>>
> > >>>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha),
> then
> > >>>>>>> the
> > >>>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7
> was
> > >>>>>>> released it would probably break again.
> > >>>>>>>
> > >>>>>>> This is all too counter-intuitive. The current version of SLF4J
> is
> > >>>>>>> 1.7.1.
> > >>>>>>> If my project was to be built against it, knowing that there is a
> > >>>>>>> likelihood of an incompatible change being introduced in 1.8.0
> > (SLF4J
> > >>>>>>> does
> > >>>>>>> not adhere to SemVer), I would like to define my version range
> for
> > >>>>>>> slf4j-api as [1.7.0,1.8.0). I
> > >>>>>>>
> > >>>>>>>  I think you do [1.7.0,1.8.0-!)
> > >>>>>>
> > >>>>>> but that might just include 1.8.0-SNAPSHOT
> > >>>>>>
> > >>>>>>   have no way of knowing before the time what type of -RC0,
> -alpha2
> > >>>>>>
> > >>>>>>> qualified releases will be made for 1.8.0, so I can only exclude
> > >>>>>>> 1.8.0.
> > >>>>>>>
> > >>>>>>> However, when 1.8.0-alpha2 is released with incompatible changes,
> > my
> > >>>>>>> build
> > >>>>>>> will immediately be broken.
> > >>>>>>>
> > >>>>>>> I could depend on version 1.5.11 directly, without using a
> version
> > >>>>>>> range,
> > >>>>>>> but Maven considers this a soft version dependency and will
> ignore
> > it
> > >>>>>>> as
> > >>>>>>> needed.
> > >>>>>>>
> > >>>>>>> It is apparent that there is no reliable way to define a
> > >>>>>>> compatibility
> > >>>>>>> range in Maven. I feel that this should be a major concern to all
> > >>>>>>> Maven
> > >>>>>>> users and developers.
> > >>>>>>>
> > >>>>>>> It would be a shame for all the effort made by the Maven
> community
> > to
> > >>>>>>> make
> > >>>>>>> software builds stable and reproducible to be undermined by
> > >>>>>>> consistent,
> > >>>>>>> predictable breakage described above.
> > >>>>>>>
> > >>>>>>> I have read in mailing list archives that the suggested way of
> > >>>>>>> excluding
> > >>>>>>> all 1.8.0 pre-release version is to define an exclusive upper
> bound
> > >>>>>>> as
> > >>>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated
> above
> > >>>>>>> with
> > >>>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all
> for a
> > >>>>>>> user
> > >>>>>>> to
> > >>>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0.
> > >>>>>>>
> > >>>>>>> My proposal is that the qualifier is ignored when comparing a
> > version
> > >>>>>>> to
> > >>>>>>> the version number declared in an exclusive upper bound. ie.
> > >>>>>>> 1.6.0-xyz
> > >>>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and
> therefore
> > >>>>>>> considered to fall outside of the version range. Importantly, it
> > >>>>>>> should
> > >>>>>>> only be for the special case of comparing to the version number
> in
> > an
> > >>>>>>> exclusive upper bound.
> > >>>>>>>
> > >>>>>>> If the powers that be see fit, an exception could be made for
> > service
> > >>>>>>> pack
> > >>>>>>> qualifiers, which according to one web page on Maven version
> > >>>>>>> ordering I
> > >>>>>>> read, should be sorted after the release, although I would prefer
> > to
> > >>>>>>> see
> > >>>>>>> Maven more closely aligned to SemVer, where all qualified version
> > >>>>>>> numbers
> > >>>>>>> are considered pre-release versions. I consider 1.7.2 a better
> > >>>>>>> version
> > >>>>>>> number than 1.7.1-sp1.
> > >>>>>>>
> > >>>>>>> Ultimately, I would like to be able to make things as easy as
> > >>>>>>> possible
> > >>>>>>> for
> > >>>>>>> users depending on a library that adheres to SemVer, to define a
> > >>>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it
> > >>>>>>> should
> > >>>>>>> not
> > >>>>>>> be as easy as that.
> > >>>>>>>
> > >>>>>>> Please consider fixing this soon.
> > >>>>>>>
> > >>>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus
> Jira.
> > >>>>>>> The
> > >>>>>>> signup link on this page displays an error:
> > >>>>>>> http://maven.apache.org/users/
> > >>>>>>> **getting-help.html <http://maven.apache.org/****
> > >>>>>>> users/getting-help.html<
> > http://maven.apache.org/**users/getting-help.html>
> > >>>>>>> <http:/**/maven.apache.org/users/**getting-help.html<
> > http://maven.apache.org/users/getting-help.html>
> > >>>>>>> >
> > >>>>>>>
> > >>>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to
> this
> > >>>>>>> issue,
> > >>>>>>> but the initial report is for a similar issue, not this issue.
> The
> > >>>>>>> issue
> > >>>>>>> I
> > >>>>>>> describe above is reported and discussed in the comments for
> > MNG-3092
> > >>>>>>> though.
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Jesse
> > >>>>>>>
> > >>>>>>>
> > ------------------------------******--------------------------**--**
> > >>>>>>> --**---------
> > >>>>>>> To unsubscribe, e-mail:
> > >>>>>>> users-unsubscribe@maven.****apac**he.org <http://apache.org><
> > >>>>>>> users-unsubscribe@**maven.**apache.org <http://maven.apache.org
> ><
> > >>>>>>> users-unsubscribe@**maven.apache.org<
> > [hidden email]>
> > >>>>>>> >
> > >>>>>>>
> > >>>>>>> For additional commands, e-mail: [hidden email]
> > >>>>>>>
> > >>>>>>>  ------------------------------****----------------------------**
> > >>>>>> --**
> > >>>>>>
> > >>>>> ---------
> > >>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
> > http://apache.org>
> > >>>>> <users-unsubscribe@**maven.apache.org<
> > [hidden email]>
> > >>>>> >
> > >>>>> For additional commands, e-mail: [hidden email]
> > >>>>>
> > >>>>>  ------------------------------****----------------------------**
> > >>>> --**---------
> > >>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
> > http://apache.org>
> > >>>> <users-unsubscribe@**maven.apache.org<
> > [hidden email]>
> > >>>> >
> > >>>> For additional commands, e-mail: [hidden email]
> > >>>>
> > >>>>
> > >>>>  ------------------------------****----------------------------**
> > >>> --**---------
> > >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<
> > http://apache.org>
> > >>> <users-unsubscribe@**maven.apache.org<
> > [hidden email]>
> > >>> >
> > >>> For additional commands, e-mail: [hidden email]
> > >>>
> > >>>
> > >>>
> > >
> > >
> ------------------------------**------------------------------**---------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > [hidden email]>
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > --
> > Baptiste <Batmat> MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> > nbsp;!
> >
>
123
Loading...