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