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