subject:"Re\: Version ranges not working"

Re: Version ranges not working

2012-09-27 Thread Stephen Connolly

On 27 September 2012 14: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


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 
>
> 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
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Version ranges not working

2012-09-27 Thread 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  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 

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
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-27 Thread Joachim Van der Auwera


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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-27 Thread Hervé BOUTEMY

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  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

Re: Version ranges not working

2012-09-27 Thread Hervé BOUTEMY

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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-27 Thread Paul French


Okay I see the problem.

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


  class MavenVersion implements Comparable
  {
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  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 

Jira issue MNG-3092, reported over 5 years ago, is related to this issue,
but the initial report is for a similar issue

Re: Version ranges not working

2012-09-27 Thread Stephen Connolly

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  wrote:

> Okay I see the problem.
>
> How about allowing a user to plugin a Version class that implements
> Comparator
>
>   class MavenVersion implements Comparable
>   {
> 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  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

Re: Version ranges not working

2012-09-27 Thread 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  wrote:


Okay I see the problem.

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

   class MavenVersion implements Comparable
   {
 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  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 numbe

Re: Version ranges not working

2012-09-27 Thread Stephen Connolly

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  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  wrote:
>>
>>  Okay I see the problem.
>>>
>>> How about allowing a user to plugin a Version class that implements
>>> Comparator
>>>
>>>class MavenVersion implements Comparable
>>>{
>>>  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  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
>>> comp

Re: Version ranges not working

2012-09-27 Thread 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  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  wrote:

  Okay I see the problem.

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

class MavenVersion implements Comparable
{
  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  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 sh

Re: Version ranges not working

2012-09-27 Thread Stephen Connolly

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

On 27 September 2012 23:56, Paul French  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  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  wrote:

   Okay I see the problem.

> How about allowing a user to plugin a Version class that implements
> Comparator
>
> class MavenVersion implements Comparable
> {
>   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  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. Bu

Re: Version ranges not working

2012-09-27 Thread Baptiste MATHUS

+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 

> 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  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  wrote:
> >>
> >>  Okay I see the problem.
> >>>
> >>> How about allowing a user to plugin a Version class that implements
> >>> Comparator
> >>>
> >>>class MavenVersion implements Comparable
> >>>{
> >>>  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  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.
> >>> I

Re: Version ranges not working

2012-09-27 Thread 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

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 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 wrote:

Okay I see the problem.

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

class MavenVersion implements Comparable
{
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 :

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 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

[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,

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

as
need

Re: Version ranges not working

2012-09-27 Thread Paul French


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 


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  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  wrote:

  Okay I see the problem.

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

class MavenVersion implements Comparable
{
  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

Re: Version ranges not working

2012-09-28 Thread Jesse Long

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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-28 Thread Jesse Long


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  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 dire

Re: Version ranges not working

2012-09-28 Thread Mark Struberg

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 
> To: Maven Users List 
> 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  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  
> 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 
>  wrote:
>>>>> 
>>>>>    Okay I see the problem.
>>>>> 
>>>>>>  How about allowing a user to plugin a Version class that 
> implements
>>>>>>  Comparator
>>>>>> 
>>>>>>      class MavenVersion implements 
> Comparable
>>>>>>      {
>>>>>>        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-alph

Re: Version ranges not working

2012-09-28 Thread Ron Wheeler

On 28/09/2012 3:17 AM, Jesse Long wrote:
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.*.

I am not sure how version ranges will help you in this case.
Your mythical user is overriding your version 1.5.* with 1.6.* so he
will be in trouble using your library regardless of what you put in your
dependency.

If your library is clearly documented as not being compatible with
versions after 1.5.*, then the user is responsible for making sure that
nothing brings in a later version of slf4j.

You had better write a big note about your restriction since most of us
will just put an exclusion on your transitive dependency for slf4j and
run with the version that we want.

There are not many good libraries that are not upwards compatible and it
is generally safe to run with the latest version of everything.
The good library authors will change the artifact name if the new
version is not capable of supporting code written for the previous version.

I have yet to see a good case for version ranges and it seems that they
cause these sort of discussions every year or so.

Ron

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

)

Cheers

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-28 Thread David Hoffer

I find this topic interesting for a couple of reasons.  I was one of the
original posters of this topic and created some of the relevant JIRA issues
regarding it.

However one of the problems is that since this issue was never fixed...and
sadly seems never will be...we had to abandon the use of version ranges.  I
do not agree they are a bad idea.  I think they could have been a very
useful feature if implemented as originally proposed.
 (The fundamental problem was that they did not exclude SNAPSHOTS as
originally intended/stated.)

Effectively we had to work around the lack of version ranges by just
building against SNAPSHOTS instead (I'm talking about internal code here).
 So effectively the SNAPSHOT became our version range.  One of the problems
of this approach is now I have to toggle between going offline/online if I
don't want to accept new updates since it will be changing on a regular
basis.  Using version ranges would have been a more elegant solution as it
would give me more control over what versions I depend on during
development.

Because it wasn't fixed and we had to do the workaround I have not been
close to this issue anymore...its been like 5 years or more.  But the short
answer is it should be fixed and it can/could be useful as some have
indicated in this discussion.

-Dave

On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler  wrote:

>
> On 28/09/2012 3:17 AM, Jesse Long wrote:
>
>> 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.*.
>>
>>  I am not sure how version ranges will help you in this case.
> Your mythical user is overriding your version 1.5.* with 1.6.* so he will
> be in trouble using your library regardless of what you put in your
> dependency.
>
> If your library is clearly documented as not being compatible with
> versions after 1.5.*, then the user is responsible for making sure that
> nothing brings in a later version of slf4j.
>
> You had better write a big note about your restriction since most of us
> will just put an exclusion on your transitive dependency  for slf4j and run
> with the version that we want.
>
> There are not many good libraries that are not upwards compatible and it
> is generally safe to run with the latest version of everything.
> The good library authors will change the artifact name if the new version
> is not capable of supporting code written for the previous version.
>
> I have yet to see a good case for version ranges and it seems that they
> cause these sort of discussions every year or so.
>
> Ron
>
>  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: 
>> users-unsubscribe@maven.**apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@maven.**apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Version ranges not working

2012-09-28 Thread Jesse Long


On 28/09/2012 14:42, Ron Wheeler wrote:


On 28/09/2012 3:17 AM, Jesse Long wrote:
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.*.



I am not sure how version ranges will help you in this case.
Your mythical user is overriding your version 1.5.* with 1.6.* so he 
will be in trouble using your library regardless of what you put in 
your dependency.


If your library is clearly documented as not being compatible with 
versions after 1.5.*, then the user is responsible for making sure 
that nothing brings in a later version of slf4j.


You had better write a big note about your restriction since most of 
us will just put an exclusion on your transitive dependency for slf4j 
and run with the version that we want.


There are not many good libraries that are not upwards compatible and 
it is generally safe to run with the latest version of everything.
The good library authors will change the artifact name if the new 
version is not capable of supporting code written for the previous 
version.


I have yet to see a good case for version ranges and it seems that 
they cause these sort of discussions every year or so.


Ron


My library does clearly document the versions of slf4j it depends on - 
as a version range in the pom.xml file. How else?


Never mind slf4j for the time being, this affects all libraries.

Please see http://semver.org/

The whole purpose of having a major version number is to clearly 
indicate when incompatibility is introduced. It does get introduced, often.


Cheers,
Jesse


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-28 Thread Graham Leggett

On 28 Sep 2012, at 4:13 PM, Jesse Long  wrote:

> My library does clearly document the versions of slf4j it depends on - as a 
> version range in the pom.xml file. How else?
> 
> Never mind slf4j for the time being, this affects all libraries.
> 
> Please see http://semver.org/
> 
> The whole purpose of having a major version number is to clearly indicate 
> when incompatibility is introduced. It does get introduced, often.

In turn, this is why maven goes on about repeatability - so that when you need 
to rebuild your code in an emergency to apply that critical bug fix to live, 
your code builds first time, every time.

If you're someone like Redhat, and can hire a bunch of people to release 
packages with dependencies that follow the rule that ABI compatibility is 
maintained at all times, then you're fine. But if you're depending on various 
libraries released by various independent people and organisations with no 
guarantees of anything, then pinning the version numbers is the only sane thing 
to do.

Regards,
Graham
--

smime.p7s
Description: S/MIME cryptographic signature

Re: Version ranges not working

2012-09-28 Thread Ron Wheeler


On 28/09/2012 10:31 AM, Graham Leggett wrote:

On 28 Sep 2012, at 4:13 PM, Jesse Long  wrote:


My library does clearly document the versions of slf4j it depends on - as a 
version range in the pom.xml file. How else?
If you are selling or distributing your product, it should be front and 
center in your user documentation.


*NOTE: This package will not run with any version of slf4j later than 
1.5.11.*


Practically no one reads poms of libraries that they use as 
dependencies. Documentation - yes; POMs - no.
Without that warning, I would simply exclude your transitive 
dependencies and put in the version of slf4j that we support officially 
for our builds and be pissed when I figured out that your code was tied 
in some way to an obsolete version of slf4j without a *BIG* warning.


When one builds big projects, there are lots of different versions of 
common libraries called up.
If you are watching your dependencies carefully, you look at the 
dependency tree and graph and decide which version to run and exclude 
the transitive dependencies on artifacts that call up versions that you 
do not want to run.





Never mind slf4j for the time being, this affects all libraries.
slf4j is probably pretty benign but my distress would be much greater 
for other libraries that would affect the actual results produced.




Please see http://semver.org/

The whole purpose of having a major version number is to clearly indicate when 
incompatibility is introduced. It does get introduced, often.
Not acceptable. If a developer is not going to provide upward 
compatibility, then they should change the Artifact id to be sure that 
no one gets hurt because of the laziness or lack of thoughtfulness or 
just plain bad design of the older version.

Major versions are not incompatible in most libraries.
Hibernate is a good example where the developers realized that version 3 
was completely different from versions.
If they wanted to have reasonably method names without the danger of 
people getting hurt by trying to run code written to version 2 specs 
against version 3, they had to rename the artifacts.





In turn, this is why maven goes on about repeatability - so that when you need 
to rebuild your code in an emergency to apply that critical bug fix to live, 
your code builds first time, every time.

If you're someone like Redhat, and can hire a bunch of people to release 
packages with dependencies that follow the rule that ABI compatibility is 
maintained at all times, then you're fine. But if you're depending on various 
libraries released by various independent people and organisations with no 
guarantees of anything, then pinning the version numbers is the only sane thing 
to do.

Agreed.
And you might want to warn your users about the bad things that will 
happen because of a problem in a transitive dependency even if it is not 
your fault.



Regards,
Graham
--




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Version ranges not working

2012-09-28 Thread Hervé BOUTEMY

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

Maven defines some qualifiers: see [1] for exact list (notice the synonyms, 
even 
for the release, that can be "ga" or "final")
I chose the qualifiers from what I could see that didn't have multiple 
interpretations: yes, MR is not a good candidate

Even the "a" and "b" qualifiers, which are actually synonyms for "alpha" and 
"beta", are sometimes used for maintenance release: well known example is 
javax.transaction 1.0.1B which is not a beta but maintenance release
But the choice was to ignore such exceptions and support "a" and "b" for alpha 
and beta shortcuts

Regards,

Hervé

[1] 
http://maven.apache.org/ref/3.0.4/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html

Le vendredi 28 septembre 2012 09:09:19 Mark Struberg a écrit :
> 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 
> > To: Maven Users List 
> > 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  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 
> > 
> > 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
> >

Re: Version ranges not working

2012-09-28 Thread Hervé BOUTEMY

yes, https://jira.codehaus.org/browse/MNG-3092 is still here

I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do 
so, it's not a *range* any more but a range + a filter
(1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english")

and actual discussion helps me dig into other ideas that could be useful: 
IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and 
beta too, no?
But I'm not sure about the use case (and "Guide to using version ranges" still 
needs to be written: https://jira.codehaus.org/browse/MNG-1368)
I understand that when a library is at 1.9 and someone needs old 1.8-, he 
implictely wants releases, not alpha nor SNAPSHOTS
But if 1.8 is still not out, and there is still work on 1.7.x, we need to 
accept *latest* 1.7.x whatever its maturity level is


Really , excluding version from a mathematical range is another operation that 
needs some specification and probably something more expressive than [min,max]

Regards,

Hervé

Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit :
> I find this topic interesting for a couple of reasons.  I was one of the
> original posters of this topic and created some of the relevant JIRA issues
> regarding it.
> 
> However one of the problems is that since this issue was never fixed...and
> sadly seems never will be...we had to abandon the use of version ranges.  I
> do not agree they are a bad idea.  I think they could have been a very
> useful feature if implemented as originally proposed.
>  (The fundamental problem was that they did not exclude SNAPSHOTS as
> originally intended/stated.)
> 
> Effectively we had to work around the lack of version ranges by just
> building against SNAPSHOTS instead (I'm talking about internal code here).
>  So effectively the SNAPSHOT became our version range.  One of the problems
> of this approach is now I have to toggle between going offline/online if I
> don't want to accept new updates since it will be changing on a regular
> basis.  Using version ranges would have been a more elegant solution as it
> would give me more control over what versions I depend on during
> development.
> 
> Because it wasn't fixed and we had to do the workaround I have not been
> close to this issue anymore...its been like 5 years or more.  But the short
> answer is it should be fixed and it can/could be useful as some have
> indicated in this discussion.
> 
> -Dave
> 
> On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler  > wrote:
> > 
> > On 28/09/2012 3:17 AM, Jesse Long wrote:
> >> 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.*.
> >> 
> >>  I am not sure how version ranges will help you in this case.
> > 
> > Your mythical user is overriding your version 1.5.* with 1.6.* so he will
> > be in trouble using your library regardless of what you put in your
> > dependency.
> > 
> > If your library is clearly documented as not being compatible with
> > versions after 1.5.*, then the user is responsible for making sure that
> > nothing brings in a later version of slf4j.
> > 
> > You had better write a big note about your restriction since most of us
> > will just put an exclusion on your transitive dependency  for slf4j and
> > run
> > with the version that we want.
> > 
> > There are not many good libraries that are not upwards compatible and it
> > is generally safe to run with the latest version of everything.
> > The good library authors will change the artifact name if the new version
> > is not capable of supporting code written for the previous version.
> > 
> > I have yet to see a good case for version ranges and it seems that they
> > cause these sort of discussions every year or so.
> > 
> > Ron
> > 
> >  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 >>> ople/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 a

Re: Version ranges not working

2012-09-28 Thread Hervé BOUTEMY

Le vendredi 28 septembre 2012 09:52:50 Jesse Long a écrit :
> My point is really about exclusive upper bounds.
ok, now I'm starting to see the precise idea and believe it can avoid breaking 
subtle logic
[1.7,1.8) could exclude anything "starting with" 1.8: betas, alphas, alphas-
alphas, snapshots (but this one is a consequence of excluding alphas since 
alpha < snapshot)
it's still a mathematical range, just the meaning of the upper bound is 
different and intended as more natural

Changing this behaviour would need good documentation and communication, but 
seems feasible without wrecking havoc

You'll need to create a Jira issue, perhaps have a vote on the list to check 
that nobody finds big issues with this change (or see the benefit of breaking 
past-compatibility)

> 
> 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.
ouch, 1.8.* release versions in [1.7,1.8]?
Service packs (1.8-sp1), why not, even if not immediately natural
but 1.8.1, no, sorry :)

> 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.
+1

> 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.
I don't think we need special handling: with "exclude anything starting with" 
semantics and the version comparison algorithm, IMHO, we have the rule that 
can be applied to any form of upper bound and stays completely logic and 
previsible
The more I dig into this semantic, the more I like it :)

A new question: what about exclusive lower bound? would this semantic apply 
too? (I'm tired for the moment, just throwing the question without having 
really thought about consequences)


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-29 Thread Mark Struberg

I thought about mathematical ranges as well, and the outcome for me personally 
that a strict mathematical time vector interpretation makes no sense for maven.


You have a library in version 1.7.0 which fits your project.

Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary 
incompatible change.

But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. 

Also: for most dependencies you only like to get released versions via your 
version range. But as I read here some use this internally as well and like to 
get SNAPSHOTS resolved. 

What about simply writing up what people like to have and then implement a new 
mechanism?
I could even think about regexp based versioning...

LieGrue,
strub




- Original Message -
> From: Hervé BOUTEMY 
> To: Maven Users List 
> Cc: 
> Sent: Saturday, September 29, 2012 5:06 AM
> Subject: Re: Version ranges not working
> 
> yes, https://jira.codehaus.org/browse/MNG-3092 is still here
> 
> I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we 
> do 
> so, it's not a *range* any more but a range + a filter
> (1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english")
> 
> and actual discussion helps me dig into other ideas that could be useful: 
> IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and 
> beta too, no?
> But I'm not sure about the use case (and "Guide to using version 
> ranges" still 
> needs to be written: https://jira.codehaus.org/browse/MNG-1368)
> I understand that when a library is at 1.9 and someone needs old 1.8-, he 
> implictely wants releases, not alpha nor SNAPSHOTS
> But if 1.8 is still not out, and there is still work on 1.7.x, we need to 
> accept *latest* 1.7.x whatever its maturity level is
> 
> 
> Really , excluding version from a mathematical range is another operation 
> that 
> needs some specification and probably something more expressive than [min,max]
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit :
>>  I find this topic interesting for a couple of reasons.  I was one of the
>>  original posters of this topic and created some of the relevant JIRA issues
>>  regarding it.
>> 
>>  However one of the problems is that since this issue was never fixed...and
>>  sadly seems never will be...we had to abandon the use of version ranges.  I
>>  do not agree they are a bad idea.  I think they could have been a very
>>  useful feature if implemented as originally proposed.
>>   (The fundamental problem was that they did not exclude SNAPSHOTS as
>>  originally intended/stated.)
>> 
>>  Effectively we had to work around the lack of version ranges by just
>>  building against SNAPSHOTS instead (I'm talking about internal code 
> here).
>>   So effectively the SNAPSHOT became our version range.  One of the problems
>>  of this approach is now I have to toggle between going offline/online if I
>>  don't want to accept new updates since it will be changing on a regular
>>  basis.  Using version ranges would have been a more elegant solution as it
>>  would give me more control over what versions I depend on during
>>  development.
>> 
>>  Because it wasn't fixed and we had to do the workaround I have not been
>>  close to this issue anymore...its been like 5 years or more.  But the short
>>  answer is it should be fixed and it can/could be useful as some have
>>  indicated in this discussion.
>> 
>>  -Dave
>> 
>>  On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler 
> >  > wrote:
>>  > 
>>  > On 28/09/2012 3:17 AM, Jesse Long wrote:
>>  >> 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.*.
>>  >> 
>>  >>  I am not sure how version ranges will help you in this case.
>>  > 
>>  > Your mythical user is overriding your version 1.5.* with 1.6.* so he 
> will
>>  > be in trouble using your library regardless of what you put in your
>>  > dependency.
>>  > 
>>  > If your library is clearly documented as not being compatible with
>>  > versions after 1.5.*, then the

Re: Version ranges not working

2012-09-29 Thread Hervé BOUTEMY

Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit :
> I thought about mathematical ranges as well, and the outcome for me
> personally that a strict mathematical time vector interpretation makes no
> sense for maven.
> 
> 
> You have a library in version 1.7.0 which fits your project.
> 
> Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary
> incompatible change.
> 
> But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still.
> 
> Also: for most dependencies you only like to get released versions via your
> version range. But as I read here some use this internally as well and like
> to get SNAPSHOTS resolved.
a range tells about a constraint
then choosing a precise version between the multiple choices that match 
constraints is not about the range but about what is usually called "conflict 
resolution"
This term is ok when it's about changing preferred version (ie when versions 
are not defined as range but as simple version, which means preferred version)
but that term doesn't show that when it's about ranges, it's not about conflict 
but about choosing one version between the multiple valid choices: do you 
prefer the most recent? even if it is a snapshot or an alpha? or if the most 
recent is an alpha, you prefer to stick with stable version?
IMHO, during development, you can want to test latest alpha SNAPSHOT, but when 
doing a release, you'll prefer stable versions

> 
> What about simply writing up what people like to have and then implement a
> new mechanism? I could even think about regexp based versioning...
sure, there is something to create here, but IMHO not into version ranges: 
into conflict resolution specification and switch (with CLI or IDE)

> 
> LieGrue,
> strub
> 
> 
> 
> 
> - Original Message -
> 
> > From: Hervé BOUTEMY 
> > To: Maven Users List 
> > Cc:
> > Sent: Saturday, September 29, 2012 5:06 AM
> > Subject: Re: Version ranges not working
> > 
> > yes, https://jira.codehaus.org/browse/MNG-3092 is still here
> > 
> > I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we
> > do
> > so, it's not a *range* any more but a range + a filter
> > (1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english")
> > 
> > and actual discussion helps me dig into other ideas that could be useful:
> > IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas
> > and beta too, no?
> > But I'm not sure about the use case (and "Guide to using version
> > ranges" still
> > needs to be written: https://jira.codehaus.org/browse/MNG-1368)
> > I understand that when a library is at 1.9 and someone needs old 1.8-, he
> > implictely wants releases, not alpha nor SNAPSHOTS
> > But if 1.8 is still not out, and there is still work on 1.7.x, we need to
> > accept *latest* 1.7.x whatever its maturity level is
> > 
> > 
> > Really , excluding version from a mathematical range is another operation
> > that needs some specification and probably something more expressive than
> > [min,max]
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit :
> >>  I find this topic interesting for a couple of reasons.  I was one of the
> >>  original posters of this topic and created some of the relevant JIRA
> >>  issues
> >>  regarding it.
> >>  
> >>  However one of the problems is that since this issue was never
> >>  fixed...and
> >>  sadly seems never will be...we had to abandon the use of version
> >>  ranges.  I
> >>  do not agree they are a bad idea.  I think they could have been a very
> >>  useful feature if implemented as originally proposed.
> >> 
> >>   (The fundamental problem was that they did not exclude SNAPSHOTS as
> >> 
> >>  originally intended/stated.)
> >>  
> >>  Effectively we had to work around the lack of version ranges by just
> >>  building against SNAPSHOTS instead (I'm talking about internal code
> > 
> > here).
> > 
> >>   So effectively the SNAPSHOT became our version range.  One of the
> >> problems>> 
> >>  of this approach is now I have to toggle between going offline/online if
> >>  I
> >>  don't want to accept new updates since it will be changing on a regular
> >>  basis.  Using version ranges would have been a more elegant solution as
> >>  it
> >>  would give me more control over what versions I depend on during
> >>  development.
> >>  
> >>

Re: Version ranges not working

2012-09-29 Thread Stephen Connolly

The issue I see is that there is a difference with ranges between build
time and run time.

In general at build time you want the lowest version in the range (assuming
the api is versions correctly) to ensure you are compatible with the
smallest set of api method signatures.

At run time you want the highest as it has the most big fixes in theory.

At test time you ideally want every version. But that matrixes out to an
impossible combinatorial.

On Saturday, 29 September 2012, Hervé BOUTEMY wrote:

> Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit :
> > I thought about mathematical ranges as well, and the outcome for me
> > personally that a strict mathematical time vector interpretation makes no
> > sense for maven.
> >
> >
> > You have a library in version 1.7.0 which fits your project.
> >
> > Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary
> > incompatible change.
> >
> > But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still.
> >
> > Also: for most dependencies you only like to get released versions via
> your
> > version range. But as I read here some use this internally as well and
> like
> > to get SNAPSHOTS resolved.
> a range tells about a constraint
> then choosing a precise version between the multiple choices that match
> constraints is not about the range but about what is usually called
> "conflict
> resolution"
> This term is ok when it's about changing preferred version (ie when
> versions
> are not defined as range but as simple version, which means preferred
> version)
> but that term doesn't show that when it's about ranges, it's not about
> conflict
> but about choosing one version between the multiple valid choices: do you
> prefer the most recent? even if it is a snapshot or an alpha? or if the
> most
> recent is an alpha, you prefer to stick with stable version?
> IMHO, during development, you can want to test latest alpha SNAPSHOT, but
> when
> doing a release, you'll prefer stable versions
>
> >
> > What about simply writing up what people like to have and then implement
> a
> > new mechanism? I could even think about regexp based versioning...
> sure, there is something to create here, but IMHO not into version ranges:
> into conflict resolution specification and switch (with CLI or IDE)
>
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > - Original Message -
> >
> > > From: Hervé BOUTEMY 
> > > To: Maven Users List 
> > > Cc:
> > > Sent: Saturday, September 29, 2012 5:06 AM
> > > Subject: Re: Version ranges not working
> > >
> > > yes, https://jira.codehaus.org/browse/MNG-3092 is still here
> > >
> > > I'm not comfortable with the idea of excluding SNAPSHOT from ranges:
> if we
> > > do
> > > so, it's not a *range* any more but a range + a filter
> > > (1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english")
> > >
> > > and actual discussion helps me dig into other ideas that could be
> useful:
> > > IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but
> alphas
> > > and beta too, no?
> > > But I'm not sure about the use case (and "Guide to using version
> > > ranges" still
> > > needs to be written: https://jira.codehaus.org/browse/MNG-1368)
> > > I understand that when a library is at 1.9 and someone needs old 1.8-,
> he
> > > implictely wants releases, not alpha nor SNAPSHOTS
> > > But if 1.8 is still not out, and there is still work on 1.7.x, we need
> to
> > > accept *latest* 1.7.x whatever its maturity level is
> > >
> > >
> > > Really , excluding version from a mathematical range is another
> operation
> > > that needs some specification and probably something more expressive
> than
> > > [min,max]
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit :
> > >>  I find this topic interesting for a couple of reasons.  I was one of
> the
> > >>  original posters of this topic and created some of the relevant JIRA
> > >>  issues
> > >>  regarding it.
> > >>
> > >>  However one of the problems is that since this issue was never
> > >>  fixed...and
> > >>  sadly seems never will be...we had to abandon the use of version
> > >>  ranges.  I
> > >>  do not agree they are a bad idea.  I think they could have been a
> very
> &g

Re: Version ranges not working

2012-09-29 Thread Hervé BOUTEMY

yes, that's my point: ranges are the same, but version to choose are different

the solution won't come from ranges tweak but conflict resolution improvements

Le samedi 29 septembre 2012 17:31:29 Stephen Connolly a écrit :
> The issue I see is that there is a difference with ranges between build
> time and run time.
> 
> In general at build time you want the lowest version in the range (assuming
> the api is versions correctly) to ensure you are compatible with the
> smallest set of api method signatures.
> 
> At run time you want the highest as it has the most big fixes in theory.
> 
> At test time you ideally want every version. But that matrixes out to an
> impossible combinatorial.
> 
> On Saturday, 29 September 2012, Hervé BOUTEMY wrote:
> > Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit :
> > > I thought about mathematical ranges as well, and the outcome for me
> > > personally that a strict mathematical time vector interpretation makes
> > > no
> > > sense for maven.
> > > 
> > > 
> > > You have a library in version 1.7.0 which fits your project.
> > > 
> > > Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary
> > > incompatible change.
> > > 
> > > But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still.
> > > 
> > > Also: for most dependencies you only like to get released versions via
> > 
> > your
> > 
> > > version range. But as I read here some use this internally as well and
> > 
> > like
> > 
> > > to get SNAPSHOTS resolved.
> > 
> > a range tells about a constraint
> > then choosing a precise version between the multiple choices that match
> > constraints is not about the range but about what is usually called
> > "conflict
> > resolution"
> > This term is ok when it's about changing preferred version (ie when
> > versions
> > are not defined as range but as simple version, which means preferred
> > version)
> > but that term doesn't show that when it's about ranges, it's not about
> > conflict
> > but about choosing one version between the multiple valid choices: do you
> > prefer the most recent? even if it is a snapshot or an alpha? or if the
> > most
> > recent is an alpha, you prefer to stick with stable version?
> > IMHO, during development, you can want to test latest alpha SNAPSHOT, but
> > when
> > doing a release, you'll prefer stable versions
> > 
> > > What about simply writing up what people like to have and then implement
> > 
> > a
> > 
> > > new mechanism? I could even think about regexp based versioning...
> > 
> > sure, there is something to create here, but IMHO not into version ranges:
> > into conflict resolution specification and switch (with CLI or IDE)
> > 
> > > LieGrue,
> > > strub
> > > 
> > > 
> > > 
> > > 
> > > - Original Message -
> > > 
> > > > From: Hervé BOUTEMY 
> > > > To: Maven Users List 
> > > > Cc:
> > > > Sent: Saturday, September 29, 2012 5:06 AM
> > > > Subject: Re: Version ranges not working
> > > > 
> > > > yes, https://jira.codehaus.org/browse/MNG-3092 is still here
> > 
> > > > I'm not comfortable with the idea of excluding SNAPSHOT from ranges:
> > if we
> > 
> > > > do
> > > > so, it's not a *range* any more but a range + a filter
> > > > (1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english")
> > > > 
> > > > and actual discussion helps me dig into other ideas that could be
> > 
> > useful:
> > > > IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but
> > 
> > alphas
> > 
> > > > and beta too, no?
> > > > But I'm not sure about the use case (and "Guide to using version
> > > > ranges" still
> > > > needs to be written: https://jira.codehaus.org/browse/MNG-1368)
> > > > I understand that when a library is at 1.9 and someone needs old 1.8-,
> > 
> > he
> > 
> > > > implictely wants releases, not alpha nor SNAPSHOTS
> > > > But if 1.8 is still not out, and there is still work on 1.7.x, we need
> > 
> > to
> > 
> > > > accept *latest* 1.7.x whatever its maturity level is
> > > > 
> > > > 
> > > > Really , excluding version from a mathematical range is

Re: Version ranges not working

2012-09-29 Thread Jason van Zyl

ht about mathematical ranges as well, and the outcome for me
>>> personally that a strict mathematical time vector interpretation makes no
>>> sense for maven.
>>> 
>>> 
>>> You have a library in version 1.7.0 which fits your project.
>>> 
>>> Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary
>>> incompatible change.
>>> 
>>> But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still.
>>> 
>>> Also: for most dependencies you only like to get released versions via
>> your
>>> version range. But as I read here some use this internally as well and
>> like
>>> to get SNAPSHOTS resolved.
>> a range tells about a constraint
>> then choosing a precise version between the multiple choices that match
>> constraints is not about the range but about what is usually called
>> "conflict
>> resolution"
>> This term is ok when it's about changing preferred version (ie when
>> versions
>> are not defined as range but as simple version, which means preferred
>> version)
>> but that term doesn't show that when it's about ranges, it's not about
>> conflict
>> but about choosing one version between the multiple valid choices: do you
>> prefer the most recent? even if it is a snapshot or an alpha? or if the
>> most
>> recent is an alpha, you prefer to stick with stable version?
>> IMHO, during development, you can want to test latest alpha SNAPSHOT, but
>> when
>> doing a release, you'll prefer stable versions
>> 
>>> 
>>> What about simply writing up what people like to have and then implement
>> a
>>> new mechanism? I could even think about regexp based versioning...
>> sure, there is something to create here, but IMHO not into version ranges:
>> into conflict resolution specification and switch (with CLI or IDE)
>> 
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
>>> - Original Message -
>>> 
>>>> From: Hervé BOUTEMY 
>>>> To: Maven Users List 
>>>> Cc:
>>>> Sent: Saturday, September 29, 2012 5:06 AM
>>>> Subject: Re: Version ranges not working
>>>> 
>>>> yes, https://jira.codehaus.org/browse/MNG-3092 is still here
>>>> 
>>>> I'm not comfortable with the idea of excluding SNAPSHOT from ranges:
>> if we
>>>> do
>>>> so, it's not a *range* any more but a range + a filter
>>>> (1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english")
>>>> 
>>>> and actual discussion helps me dig into other ideas that could be
>> useful:
>>>> IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but
>> alphas
>>>> and beta too, no?
>>>> But I'm not sure about the use case (and "Guide to using version
>>>> ranges" still
>>>> needs to be written: https://jira.codehaus.org/browse/MNG-1368)
>>>> I understand that when a library is at 1.9 and someone needs old 1.8-,
>> he
>>>> implictely wants releases, not alpha nor SNAPSHOTS
>>>> But if 1.8 is still not out, and there is still work on 1.7.x, we need
>> to
>>>> accept *latest* 1.7.x whatever its maturity level is
>>>> 
>>>> 
>>>> Really , excluding version from a mathematical range is another
>> operation
>>>> that needs some specification and probably something more expressive
>> than
>>>> [min,max]
>>>> 
>>>> Regards,
>>>> 
>>>> Hervé
>>>> 
>>>> Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit :
>>>>> I find this topic interesting for a couple of reasons.  I was one of
>> the
>>>>> original posters of this topic and created some of the relevant JIRA
>>>>> issues
>>>>> regarding it.
>>>>> 
>>>>> However one of the problems is that since this issue was never
>>>>> fixed...and
>>>>> sadly seems never will be...we had to abandon the use of version
>>>>> ranges.  I
>>>>> do not agree they are a bad idea.  I think they could have been a
>> very
>>>>> useful feature if implemented as originally proposed.
>>>>> 
>>>>>  (The fundamental problem was that they did not exclude SNAPSHOTS as
>>>>> 
>>>>> originally intended/stated.)
>>>>> 
>

Re: Version ranges not working

2012-09-29 Thread Mark Derricutt

Wait,

You're suggesting we starting encoding VERSION NUMBERING into the artefact NAME 
now? Isn't that just as bad, if not worse than the abuse of classifiers we 
already see out there?

We have the exact same issue being discussed here, and also as mentioned by 
others use OSGi. One of the key things to think of in all these situations to 
also let your artefacts work FOR you.

1) Separate out APIs from implementations - two artefacts
2) Users depend ONLY on API - NEVER implementations - mock those 
implementations for testing, or have a third "fake/test" impl.
3) Use composite artefacts for grouping common dependencies - a POM only 
artefact with dependencies, i.e. a testing pom that deps on testng, fest-assert 
etc. etc.
4) Often its only really the packaging/distribution that really needs the range 
to be resolved so maybe we should enhance the assembly plugin, or some other 
new packaging plugin.

On 29/09/2012, at 8:21 AM, Ron Wheeler  wrote:

> Not acceptable. If a developer is not going to provide upward compatibility, 
> then they should change the Artifact id to be sure that no one gets hurt 
> because of the laziness or lack of thoughtfulness or just plain bad design of 
> the older version.
> Major versions are not incompatible in most libraries.
> Hibernate is a good example where the developers realized that version 3 was 
> completely different from versions.
> If they wanted to have reasonably method names without the danger of people 
> getting hurt by trying to run code written to version 2 specs against version 
> 3, they had to rename the artifacts.

Re: Version ranges not working

2012-09-29 Thread Mark Derricutt

This idea would require a POM change, but similar to repository definitions 
having the option of declaring "release" or "snapshot"'s being enabled, maybe 
something similar could be provided for dependencies.

Or, with modifying the POM itself, we could extend the capability of the 
 attribute to somehow express "NO CLASSIFIER" which would exclude 
-SNAPSHOT, -alpha etc. etc.

Maybe  or  could handle that, which is 
different to it being absent.

This does beg the question of weather -SNAPSHOT is or is not a classifier or 
not - having -SNAPSHOT just be a "magically" part of the version and not a 
classifier has always been a bug bear, esp. with timestamp'd SNAPSHOTs breaking 
the 1-1 mapping of direction/filenames

On 29/09/2012, at 3:06 PM, Hervé BOUTEMY  wrote:

> I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do 
> so, it's not a *range* any more but a range + a filter
> (1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english")

Re: Version ranges not working

2012-09-29 Thread Mark Derricutt

+1 - we've mentioned this on the IA podcast a few times in the past - compile 
against the lower bound, run against the upper bound.

How to express that however


On 30/09/2012, at 5:31 AM, Stephen Connolly  
wrote:

> In general at build time you want the lowest version in the range (assuming
> the api is versions correctly) to ensure you are compatible with the
> smallest set of api method signatures.

Re: Version ranges not working

2012-09-29 Thread Michael McCallum

I agree with Richard, as they exist now in maven version ranges can be used
very effectively. I'm happy to post example projects if you want to know
how to do it.

If you want 'repeatability' then ranges might not be for you but if you
want determinism and releasability then ranges are for you.

Its just a matter of having good process and leveraging the tools to there
greatest effect, rather than trying to make the tool perfect.

On Sat, Sep 29, 2012 at 11:16 AM, Richard Vowles <
rich...@bluetrainsoftware.com> wrote:

> You may then be surprised to know that there are many of us for whom
> version ranges in Maven work perfectly. Ideally Maven could be more clever
> and understand that [1.6.2] is already on the local system and the metadata
> checking for ranges doesn't need to be re-fetched, but that is merely an
> optimisation. SNAPSHOTS work perfectly, ranges work perfectly, and SemVer
> is a silly waste of space.
>
> Richard
>
> On Sat, Sep 29, 2012 at 2:07 AM, David Hoffer  wrote:
>
> > I find this topic interesting for a couple of reasons.  I was one of the
> > original posters of this topic and created some of the relevant JIRA
> issues
> > regarding it.
> >
> --
> ---
> Richard Vowles,
> Grails, Groovy, Java
> Consistency is the last refuge of the unimaginative - Oscar Wilde
> ph: +64275467747, linkedin, twitter:richardvowles
> get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! -
> http://tinyurl.com/cmcceh
> podcast: http://www.illegalargument.com
>

Re: Version ranges not working

2012-09-29 Thread Michael McCallum

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  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 
>
> > 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  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 
> wrote:
> > >>
> > >>  Okay I see the problem.
> > >>>
> > >>> How about allowing a user to plugin a Version class that implements
> > >>> Comparator
> > >>>
> > >>>class MavenVersion implements Comparable
> > >>>{
> > >>>  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 
> wrote:
> > >>
> > >>  Dear Maven Community,
> > >>>
> > >>> I am writing to beg you to fix the problems with the version
> ranges
> > >>> in

Re: Version ranges not working

2012-09-29 Thread Michael McCallum

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

Re: Version ranges not working

2012-09-29 Thread Richard Vowles

The composite pattern also makes exclusion very easy.
On Sep 30, 2012 3:35 PM, "Michael McCallum"  wrote:

> 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  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 
> >
> > > 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 
> 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 
> > wrote:
> > > >>
> > > >>  Okay I see the problem.
> > > >>>
> > > >>> How about allowing a user to plugin a Version class that implements
> > > >>> Comparator
> > > >>>
> > > >>>class MavenVersion implements Comparable
> > > >>>{
> > > >>>  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
> > > >>

Re: Version ranges not working

2012-09-30 Thread Stephen Connolly

rab some shit and update itself. Probably no one.
> Really you find you need to make a change, you introduce a new artifact and
> test it again. I really don't think anyone really allows a runtime to
> update itself without strict constraints.
>
> There are distinct cases as well. If you're a SaaS you likely don't give a
> crap and you just rebuild everything and deploy it again, or you take a
> diff of the artifacts of one build to the next and send instructions to a
> node and change it to mirror the new version, or use a git repo and just
> update it. The case of Eclipse is different in that you want people to be
> able to update to newer versions. But we build m2e with very specific
> versions of bundles and then use ranges so that people with existing
> installations and use new things. But the Eclipse repository for a release
> is extremely constrained from version to version. Everyone builds against
> the same thing building up to a release and we put ranges in manifests so
> people can update, but compile time is for the most part very specific.
>
> At any rate, I believe the specification of what you compile with versus
> what you may potentially want to run with should be separated. Maven and
> OSGi get this wrong from my perspective. And it seems to me in the wild
> more people do OSGi with Maven so this muddies the water even further (the
> maven-bundle-plugin is the most used plugin outside of the core maven
> plugins).
>
> >
> > At run time you want the highest as it has the most big fixes in theory.
>
> Right, in theory you would like to leave the runtime intact for as long as
> possible absorbing changes without rebuilding if possible. But I'm not sure
> this is really done. At the most advanced development shops I've been in
> there are radical simplifications like just rebuild and redeploy the whole
> thing because Maven, along with everything else can result in problems
> primarily from configuration differences, retention policies on
> repositories but it's enough to cause problems that prevent predictable
> re-deploys. So they rebuild and redeploy the whole thing.
>
> >
> > At test time you ideally want every version. But that matrixes out to an
> > impossible combinatorial.
>
> I think you create them when necessary and they are specific and you test
> that and validate it. No one in practice tests all combinations as it's
> likely many of them are not used so why expend the resources to try them.
>
> >
> > On Saturday, 29 September 2012, Hervé BOUTEMY wrote:
> >
> >> Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit :
> >>> I thought about mathematical ranges as well, and the outcome for me
> >>> personally that a strict mathematical time vector interpretation makes
> no
> >>> sense for maven.
> >>>
> >>>
> >>> You have a library in version 1.7.0 which fits your project.
> >>>
> >>> Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary
> >>> incompatible change.
> >>>
> >>> But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still.
> >>>
> >>> Also: for most dependencies you only like to get released versions via
> >> your
> >>> version range. But as I read here some use this internally as well and
> >> like
> >>> to get SNAPSHOTS resolved.
> >> a range tells about a constraint
> >> then choosing a precise version between the multiple choices that match
> >> constraints is not about the range but about what is usually called
> >> "conflict
> >> resolution"
> >> This term is ok when it's about changing preferred version (ie when
> >> versions
> >> are not defined as range but as simple version, which means preferred
> >> version)
> >> but that term doesn't show that when it's about ranges, it's not about
> >> conflict
> >> but about choosing one version between the multiple valid choices: do
> you
> >> prefer the most recent? even if it is a snapshot or an alpha? or if the
> >> most
> >> recent is an alpha, you prefer to stick with stable version?
> >> IMHO, during development, you can want to test latest alpha SNAPSHOT,
> but
> >> when
> >> doing a release, you'll prefer stable versions
> >>
> >>>
> >>> What about simply writing up what people like to have and then
> implement
> >> a
> >>> new mechanism? I could even think about regexp based versioning...
> >> sure, there is something to create here, bu

Re: Version ranges not working

2012-09-30 Thread Laird Nelson

On Sun, Sep 30, 2012 at 12:28 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I have other thoughts but my 2.75 yr old son now is demanding to play
> racing cars on my phone, so I need to hit send on this mail now ;-)
>

I love it when priorities rear their ugly head.  :-)  Trust me when I tell
you that the racing cars on your phone are the highest priority of all.

maven-project:[3.0.3,.2.75-year-old-activities)

Best,
Laird

-- 
http://about.me/lairdnelson

Re: Version ranges not working

2012-09-30 Thread Jochen Wiedmann

And while you're at it, please take care that the absence of a
versionRange is supported.


On Thu, Sep 27, 2012 at 11:19 PM, Paul French  wrote:
> Okay I see the problem.
>
> How about allowing a user to plugin a Version class that implements
> Comparator
>
>   class MavenVersion implements Comparable
>   {
> 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  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, whe

Re: Version ranges not working

2012-09-30 Thread Ron Wheeler


Read what I wrote:
If you are making an artifact that is not upward compatible, you need to 
prevent people from thinking that they can just up the version number in 
their GAV and they will get a better version with bugs fixed.
You are in fact giving them a new artifact that will not only NOT fix 
bugs but will give the victim NoSuchMethods or NullPointers (if scope is 
"provided") in code that would work with the previous artifact.


I don't care if you use the version number as part of the new ArtifactID 
or just add the word "nouveau" at the front of the ArtifactID.

Just make sure that you change the G or the A and not just the V.

Ron

On 29/09/2012 4:50 PM, Mark Derricutt wrote:

Wait,

You're suggesting we starting encoding VERSION NUMBERING into the artefact NAME 
now? Isn't that just as bad, if not worse than the abuse of classifiers we 
already see out there?

We have the exact same issue being discussed here, and also as mentioned by 
others use OSGi. One of the key things to think of in all these situations to 
also let your artefacts work FOR you.

1) Separate out APIs from implementations - two artefacts
2) Users depend ONLY on API - NEVER implementations - mock those implementations for 
testing, or have a third "fake/test" impl.
3) Use composite artefacts for grouping common dependencies - a POM only 
artefact with dependencies, i.e. a testing pom that deps on testng, fest-assert 
etc. etc.
4) Often its only really the packaging/distribution that really needs the range 
to be resolved so maybe we should enhance the assembly plugin, or some other 
new packaging plugin.




On 29/09/2012, at 8:21 AM, Ron Wheeler  wrote:


Not acceptable. If a developer is not going to provide upward compatibility, 
then they should change the Artifact id to be sure that no one gets hurt 
because of the laziness or lack of thoughtfulness or just plain bad design of 
the older version.
Major versions are not incompatible in most libraries.
Hibernate is a good example where the developers realized that version 3 was 
completely different from versions.
If they wanted to have reasonably method names without the danger of people 
getting hurt by trying to run code written to version 2 specs against version 
3, they had to rename the artifacts.





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-30 Thread Mark Struberg

In practice it gets more complicated if you are a framework. The safest way is 
to even change your package name to reflect the API change.

LieGrue,
strub



- Original Message -
> From: Ron Wheeler 
> To: users@maven.apache.org
> Cc: 
> Sent: Sunday, September 30, 2012 7:08 PM
> Subject: Re: Version ranges not working
> 
> Read what I wrote:
> If you are making an artifact that is not upward compatible, you need to 
> prevent people from thinking that they can just up the version number in 
> their GAV and they will get a better version with bugs fixed.
> You are in fact giving them a new artifact that will not only NOT fix 
> bugs but will give the victim NoSuchMethods or NullPointers (if scope is 
> "provided") in code that would work with the previous artifact.
> 
> I don't care if you use the version number as part of the new ArtifactID 
> or just add the word "nouveau" at the front of the ArtifactID.
> Just make sure that you change the G or the A and not just the V.
> 
> Ron
> 
> On 29/09/2012 4:50 PM, Mark Derricutt wrote:
>>  Wait,
>> 
>>  You're suggesting we starting encoding VERSION NUMBERING into the 
> artefact NAME now? Isn't that just as bad, if not worse than the abuse of 
> classifiers we already see out there?
>> 
>>  We have the exact same issue being discussed here, and also as mentioned by 
> others use OSGi. One of the key things to think of in all these situations to 
> also let your artefacts work FOR you.
>> 
>>  1) Separate out APIs from implementations - two artefacts
>>  2) Users depend ONLY on API - NEVER implementations - mock those 
> implementations for testing, or have a third "fake/test" impl.
>>  3) Use composite artefacts for grouping common dependencies - a POM only 
> artefact with dependencies, i.e. a testing pom that deps on testng, 
> fest-assert 
> etc. etc.
>>  4) Often its only really the packaging/distribution that really needs the 
> range to be resolved so maybe we should enhance the assembly plugin, or some 
> other new packaging plugin.
>> 
>> 
>> 
>> 
>>  On 29/09/2012, at 8:21 AM, Ron Wheeler 
>  wrote:
>> 
>>>  Not acceptable. If a developer is not going to provide upward 
> compatibility, then they should change the Artifact id to be sure that no one 
> gets hurt because of the laziness or lack of thoughtfulness or just plain bad 
> design of the older version.
>>>  Major versions are not incompatible in most libraries.
>>>  Hibernate is a good example where the developers realized that version 
> 3 was completely different from versions.
>>>  If they wanted to have reasonably method names without the danger of 
> people getting hurt by trying to run code written to version 2 specs against 
> version 3, they had to rename the artifacts.
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-30 Thread Ron Wheeler

ems primarily from 
configuration differences, retention policies on repositories but it's enough 
to cause problems that prevent predictable re-deploys. So they rebuild and 
redeploy the whole thing.


At test time you ideally want every version. But that matrixes out to an
impossible combinatorial.

I think you create them when necessary and they are specific and you test that 
and validate it. No one in practice tests all combinations as it's likely many 
of them are not used so why expend the resources to try them.


On Saturday, 29 September 2012, Hervé BOUTEMY wrote:


Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit :

I thought about mathematical ranges as well, and the outcome for me
personally that a strict mathematical time vector interpretation makes no
sense for maven.


You have a library in version 1.7.0 which fits your project.

Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary
incompatible change.

But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still.

Also: for most dependencies you only like to get released versions via

your

version range. But as I read here some use this internally as well and

like

to get SNAPSHOTS resolved.

a range tells about a constraint
then choosing a precise version between the multiple choices that match
constraints is not about the range but about what is usually called
"conflict
resolution"
This term is ok when it's about changing preferred version (ie when
versions
are not defined as range but as simple version, which means preferred
version)
but that term doesn't show that when it's about ranges, it's not about
conflict
but about choosing one version between the multiple valid choices: do you
prefer the most recent? even if it is a snapshot or an alpha? or if the
most
recent is an alpha, you prefer to stick with stable version?
IMHO, during development, you can want to test latest alpha SNAPSHOT, but
when
doing a release, you'll prefer stable versions


What about simply writing up what people like to have and then implement

a

new mechanism? I could even think about regexp based versioning...

sure, there is something to create here, but IMHO not into version ranges:
into conflict resolution specification and switch (with CLI or IDE)


LieGrue,
strub




- Original Message -


From: Hervé BOUTEMY 
To: Maven Users List 
Cc:
Sent: Saturday, September 29, 2012 5:06 AM
Subject: Re: Version ranges not working

yes, https://jira.codehaus.org/browse/MNG-3092 is still here

I'm not comfortable with the idea of excluding SNAPSHOT from ranges:

if we

do
so, it's not a *range* any more but a range + a filter
(1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english")

and actual discussion helps me dig into other ideas that could be

useful:

IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but

alphas

and beta too, no?
But I'm not sure about the use case (and "Guide to using version
ranges" still
needs to be written: https://jira.codehaus.org/browse/MNG-1368)
I understand that when a library is at 1.9 and someone needs old 1.8-,

he

implictely wants releases, not alpha nor SNAPSHOTS
But if 1.8 is still not out, and there is still work on 1.7.x, we need

to

accept *latest* 1.7.x whatever its maturity level is


Really , excluding version from a mathematical range is another

operation

that needs some specification and probably something more expressive

than

[min,max]

Regards,

Hervé

Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit :

I find this topic interesting for a couple of reasons.  I was one of

the

original posters of this topic and created some of the relevant JIRA
issues
regarding it.

However one of the problems is that since this issue was never
fixed...and
sadly seems never will be...we had to abandon the use of version
ranges.  I
do not agree they are a bad idea.  I think they could have been a

very

useful feature if implemented as originally proposed.

  (The fundamental problem was that they did not exclude SNAPSHOTS as

originally intended/stated.)

Effectively we had to work around the lack of version ranges by just
building against SNAPSHOTS instead (I'm talking about internal code

here).


  So effectively the SNAPSHOT became our version range.  One of the
problems>>
of this approach is now I have to toggle between going

offline/online if

I
don't want to accept new updates since it will be changing on a

regular

basis.  Using version ranges would have been a more elegant solution

as

it
would give me more control over what versions I depend on during
development.

Because it wasn't fixed and we had to do the workaround I have not

been

close to this issue anymore...its been like 5 years or more.  But the
short
answer is it should be fixed and it can/could be useful as some have
indicated in this discussion.

-Dave

On Fri, Sep 28, 2012 at 6:42 AM, Ron Wh

Re: Version ranges not working

2012-09-30 Thread Benson Margulies

I think that Ron has hit the nail on the head here, and what he says
has become best practice, via many bruises, in the open source
community.

Maven has a fundamental version model. That model is does not cover
all possible real-world situations, as per JvZ's email and many
others. In particular, it makes an assumption that all new versions
are backward compatible.

Here are some assertions you could imagine making in a POM that we
can't make with Maven:

* This project provides version 3.0 of XXX.YYY. It may be used to
resolve dependencies that ask for [2.0-3.0). (And, implicitly, it may
not be used to resolve a dependency on 1.0.)

* This project provides version 3.0 of XXX.YYY. It may not be used to
resolve any dependency on an older version, but it can co-exist in the
namespace with older versions.

* This project consumes version 3.0 of XXX.YYY. If dependency
resolution tries to use some other version, fail unless the top-level
pom explicitly has a marking to force this.

* This project consumes version 5.4 of RRR.QQQ. If, somewhere in the
dependency tree, SSS.TTT asks for AAA.BBB, override any restrictions
on the version specified in SSS.TTT's pom. I know what I am doing.

Since we can't make these assertions, Ron's scheme is the only
possible scheme. If a new version is not strictly, provably, and
completely, backward-compatible, you have to change the G/A or you are
lighting the fuse on a ticking time bomb that will go off when the
resolution algorithm cheerfully substitutes an incompatible newer
version.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-30 Thread Jesse Long


On 29/09/2012 05:29, Hervé BOUTEMY wrote:

Le vendredi 28 septembre 2012 09:52:50 Jesse Long a écrit :

My point is really about exclusive upper bounds.

ok, now I'm starting to see the precise idea and believe it can avoid breaking
subtle logic
[1.7,1.8) could exclude anything "starting with" 1.8: betas, alphas, alphas-
alphas, snapshots (but this one is a consequence of excluding alphas since
alpha < snapshot)
it's still a mathematical range, just the meaning of the upper bound is
different and intended as more natural


Works for me.


Changing this behaviour would need good documentation and communication, but
seems feasible without wrecking havoc

You'll need to create a Jira issue, perhaps have a vote on the list to check
that nobody finds big issues with this change (or see the benefit of breaking
past-compatibility)


I have created a ticket - http://jira.codehaus.org/browse/MNG-5353


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.

ouch, 1.8.* release versions in [1.7,1.8]?
Service packs (1.8-sp1), why not, even if not immediately natural
but 1.8.1, no, sorry :)


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.

+1


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.

I don't think we need special handling: with "exclude anything starting with"
semantics and the version comparison algorithm, IMHO, we have the rule that
can be applied to any form of upper bound and stays completely logic and
previsible
The more I dig into this semantic, the more I like it :)

Simplicity is good. I think "starts with" is nice and simple.

A new question: what about exclusive lower bound? would this semantic apply
too? (I'm tired for the moment, just throwing the question without having
really thought about consequences)

Dont know, not really worried about it.

Thanks for taking my request seriously.

Cheers,
Jesse

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-30 Thread Jesse Long

Regarding documentation, Maven generates a dependencies report, from the 
pom.xml, which the user can read.


Regarding changing the artifactId for incompatibility, if you declare 
that you use semantic version number, then the user can tell that there 
is incompatibility by noticing that the major version number changed. He 
must do a full audit of changes when incompatibility is introduced, 
regardless of our mechanism of notifying the user that incompatibility 
has been introduced.


If you use semantic version numbering, your user will not just assume 
that the newest version is compatible. Also, it is unfair on me to just 
exclude my transitive dependencies and assume that my code will work 
with the newest version of a library I depended on. For all you know, 
the newer version of my dependency was released after I the version of 
my library you are depending on was released. How was I to know (and 
document the fact) that a later version of my dependency would be 
incompatible?


We cannot just assume that newer version are compatible. There are very 
real cases where a newer version is not compatible. I must anticipate 
that the latest version of my dependencies, as they are right now, may 
not be compatible with the latest version in 3 months time when someone 
tries to build my project. I want the Maven build to fail if the user 
ends up with an incompatible version on the classpath, and I want to be 
flexible, not forcing my user to use a specific version of my dependency 
if he needs a feature from a newer, compatible release. I can achieve 
this by depending on a version range, defined in accordance to the 
semantics of the versioning scheme of the dependency, hopefully 
http://semver.org/.


Cheers,
Jesse


On 30/09/2012 19:08, Ron Wheeler wrote:

Read what I wrote:
If you are making an artifact that is not upward compatible, you need 
to prevent people from thinking that they can just up the version 
number in their GAV and they will get a better version with bugs fixed.
You are in fact giving them a new artifact that will not only NOT fix 
bugs but will give the victim NoSuchMethods or NullPointers (if scope 
is "provided") in code that would work with the previous artifact.


I don't care if you use the version number as part of the new 
ArtifactID or just add the word "nouveau" at the front of the ArtifactID.

Just make sure that you change the G or the A and not just the V.

Ron

On 29/09/2012 4:50 PM, Mark Derricutt wrote:

Wait,

You're suggesting we starting encoding VERSION NUMBERING into the 
artefact NAME now? Isn't that just as bad, if not worse than the 
abuse of classifiers we already see out there?


We have the exact same issue being discussed here, and also as 
mentioned by others use OSGi. One of the key things to think of in 
all these situations to also let your artefacts work FOR you.


1) Separate out APIs from implementations - two artefacts
2) Users depend ONLY on API - NEVER implementations - mock those 
implementations for testing, or have a third "fake/test" impl.
3) Use composite artefacts for grouping common dependencies - a POM 
only artefact with dependencies, i.e. a testing pom that deps on 
testng, fest-assert etc. etc.
4) Often its only really the packaging/distribution that really needs 
the range to be resolved so maybe we should enhance the assembly 
plugin, or some other new packaging plugin.





On 29/09/2012, at 8:21 AM, Ron Wheeler 
 wrote:


Not acceptable. If a developer is not going to provide upward 
compatibility, then they should change the Artifact id to be sure 
that no one gets hurt because of the laziness or lack of 
thoughtfulness or just plain bad design of the older version.

Major versions are not incompatible in most libraries.
Hibernate is a good example where the developers realized that 
version 3 was completely different from versions.
If they wanted to have reasonably method names without the danger of 
people getting hurt by trying to run code written to version 2 specs 
against version 3, they had to rename the artifacts.








-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-09-30 Thread Ron Wheeler


On 30/09/2012 9:11 PM, Jesse Long wrote:
Regarding documentation, Maven generates a dependencies report, from 
the pom.xml, which the user can read.


Regarding changing the artifactId for incompatibility, if you declare 
that you use semantic version number, then the user can tell that 
there is incompatibility by noticing that the major version number 
changed. He must do a full audit of changes when incompatibility is 
introduced, regardless of our mechanism of notifying the user that 
incompatibility has been introduced.
It is only rare that a version upgrade causes a problem in a well 
followed library.
When you depend on dozens of libraries, it is very annoying to find that 
someone has screwed up a project by breaking upward compatibility.
You will find the problem at compile time if they change the G or A. If 
they only change the V, you may find out in a test if you are lucky but 
you may only find out when your clients get stack dumps instead of web 
pages.


If you use semantic version numbering, your user will not just assume 
that the newest version is compatible. Also, it is unfair on me to 
just exclude my transitive dependencies and assume that my code will 
work with the newest version of a library I depended on. For all you 
know, the newer version of my dependency was released after I the 
version of my library you are depending on was released. How was I to 
know (and document the fact) that a later version of my dependency 
would be incompatible?


You are correct. My only hope is that you have selected vendors or open 
source projects that are well managed and are careful about upward 
compatibility.


We cannot just assume that newer version are compatible. There are 
very real cases where a newer version is not compatible. I must 
anticipate that the latest version of my dependencies, as they are 
right now, may not be compatible with the latest version in 3 months 
time when someone tries to build my project. I want the Maven build to 
fail if the user ends up with an incompatible version on the 
classpath, and I want to be flexible, not forcing my user to use a 
specific version of my dependency if he needs a feature from a newer, 
compatible release. I can achieve this by depending on a version 
range, defined in accordance to the semantics of the versioning scheme 
of the dependency, hopefully http://semver.org/.


You are generally pretty safe with popular projects in assuming upwards 
compatibility since they do not want to issue a new release that no 
existing user can use without breaking their application.
If you have to tell everyone that they have to rewrite their application 
each time you issue a new version of your library, your library will 
pretty some lose its user base.


Version ranges are not required, just pick the highest one that you 
guarantee to work and leave it at that.
You can not use a higher version in a range than you have tested with. 
You should not be putting versions that will only exist in 3 months in 
your version ranges so I am not sure that I understand this paragraph.
If the user/developer wants to use a higher version a few years after 
you finish development, he/she will have to do some testing or trust 
that you have chosen well when you selected the library.



My comments about changing the G or A when you break upward 
compatibility is the best way to protect the user community if you can 
not figure out how to add new features without breaking old ones.


Most Apache projects are well run and do not break compatibility.
We use a lot of "provided" libraries in my wars since we have a set of 
about 60 libraries that we use in about 70 war files so it makes no 
sense to have these libraries in every war that we build. We use 
libraries from well managed developers who are careful about upward 
compatibility so we can be pretty adventurous about moving forward with 
the versions. Even major version changes usually preserve upward 
compatibility although I confess that I do read the docs a bit more 
carefully on a move from 1.15.3 to 2.0 than I would from 1.15.3 to 1.16.1.


Ron




Cheers,
Jesse


On 30/09/2012 19:08, Ron Wheeler wrote:

Read what I wrote:
If you are making an artifact that is not upward compatible, you need 
to prevent people from thinking that they can just up the version 
number in their GAV and they will get a better version with bugs fixed.
You are in fact giving them a new artifact that will not only NOT fix 
bugs but will give the victim NoSuchMethods or NullPointers (if scope 
is "provided") in code that would work with the previous artifact.


I don't care if you use the version number as part of the new 
ArtifactID or just add the word "nouveau" at the front of the 
ArtifactID.

Just make sure that you change the G or the A and not just the V.

Ron

On 29/09/2012 4:50 PM, Mark Derricutt wrote:

Wait,

You're suggesting we starting encoding VERSION NUMBERING into the 
artefact NAME now? Isn't that just as bad, if

Re: Version ranges not working

2012-09-30 Thread Hervé BOUTEMY

yes, please share experience about ranges: when it is useful, how, and so on
we really need to write this "Guide to using version ranges" 
https://jira.codehaus.org/browse/MNG-1368
so we stop telling "ranges are a bad practice" but tell what they are useful 
for

Regards,

Hervé

Le samedi 29 septembre 2012 12:16:43 Michael McCallum a écrit :
> I agree with Richard, as they exist now in maven version ranges can be used
> very effectively. I'm happy to post example projects if you want to know
> how to do it.
> 
> If you want 'repeatability' then ranges might not be for you but if you
> want determinism and releasability then ranges are for you.
> 
> Its just a matter of having good process and leveraging the tools to there
> greatest effect, rather than trying to make the tool perfect.
> 
> On Sat, Sep 29, 2012 at 11:16 AM, Richard Vowles <
> 
> rich...@bluetrainsoftware.com> wrote:
> > You may then be surprised to know that there are many of us for whom
> > version ranges in Maven work perfectly. Ideally Maven could be more clever
> > and understand that [1.6.2] is already on the local system and the
> > metadata
> > checking for ranges doesn't need to be re-fetched, but that is merely an
> > optimisation. SNAPSHOTS work perfectly, ranges work perfectly, and SemVer
> > is a silly waste of space.
> > 
> > Richard
> > 
> > On Sat, Sep 29, 2012 at 2:07 AM, David Hoffer  wrote:
> > > I find this topic interesting for a couple of reasons.  I was one of the
> > > original posters of this topic and created some of the relevant JIRA
> > 
> > issues
> > 
> > > regarding it.
> > 
> > --
> > ---
> > Richard Vowles,
> > Grails, Groovy, Java
> > Consistency is the last refuge of the unimaginative - Oscar Wilde
> > ph: +64275467747, linkedin, twitter:richardvowles
> > get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! -
> > http://tinyurl.com/cmcceh
> > podcast: http://www.illegalargument.com

Re: Version ranges not working

2012-09-30 Thread Hervé BOUTEMY

Le lundi 1 octobre 2012 02:31:44 Jesse Long a écrit :
> I have created a ticket - http://jira.codehaus.org/browse/MNG-5353
thank you
I changed it from "Bug" to "Wish": no, nobody ever asked for such a behaviour, 
it's really a new idea AFAIK
which BTW seems a good enhancement IMHO

now we need to check with people using ranges that it is ok for them: if 
anybody can think of a problem, please share

Regards,

Hervé

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

2012-10-01 Thread Paul French

It is clear version ranges are used by some people and they do find them 
useful including me. You cannot predict how and in what circumstances 
specific features of maven will be used by the many people out there, 
good or bad in your opinion.


I still would prefer making version range calculations pluggable where a 
default is supplied (the current). I can then create my own plugin which 
overrides the default and specify it my POM. For example I would 
probably use semantic versioning on artifacts in specific groups which I 
specify and use specific versions for others. Who knows? The fact of the 
matter is I can do what I like and the build will be repeatable (in 
terms of the version range calculation).


Currently when we release an artifact or product we have created a 
release plugin which creates an effective POM listing all versions used, 
including the transistive ones. Hence our release builds are repeatable. 
We can go back in time, branch and fix.


The biggest pain we have is the speed of the dependency calculation when 
developing. I'm sure this can be optimized.



On 01/10/2012 07:22, Hervé BOUTEMY wrote:

Le lundi 1 octobre 2012 02:31:44 Jesse Long a écrit :

I have created a ticket - http://jira.codehaus.org/browse/MNG-5353

thank you
I changed it from "Bug" to "Wish": no, nobody ever asked for such a behaviour,
it's really a new idea AFAIK
which BTW seems a good enhancement IMHO

now we need to check with people using ranges that it is ok for them: if
anybody can think of a problem, please share

Regards,

Hervé

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

50 matches

Mail list logo