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 <stephen.alan.conno...@gmail.com>
> To: Maven Users List <users@maven.apache.org>
> 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 <paul.fre...@kirona.com> 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 <paul.fre...@kirona.com>
> 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
> <paul.fre...@kirona.com> wrote:
>>>>>
>>>>> Okay I see the problem.
>>>>>
>>>>>> How about allowing a user to plugin a Version class that
> implements
>>>>>> Comparator
>>>>>>
>>>>>> class MavenVersion implements
> Comparable<MavenVersion>
>>>>>> {
>>>>>> public int compareTo(MavenVersion o)
>>>>>> {
>>>>>> // your implementation
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Then we can all do whatever we need.
>>>>>>
>>>>>>
>>>>>> On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>>>>>>
>>>>>> I understand that many people get caught
>>>>>>
>>>>>>> But what do you expect from [1.7,1.8]?
>>>>>>> And [1.7,1.8-beta)?
>>>>>>>
>>>>>>> The actual semantic is pure mathematical range,
> including or excluding
>>>>>>> an
>>>>>>> extreme
>>>>>>>
>>>>>>> since
> 1.8-alpha<1.8-beta-<1.8-rc<1.******8-SNAPSHOT<1.8, it's pure
>>>>>>> math
>>>>>>>
>>>>>>>
>>>>>>> IMHO, anything that doesn't conform mathematical
> range will have some
>>>>>>> unexpected behaviour sometime
>>>>>>>
>>>>>>> Yes, people need to learn that they usually want
>>>>>>> [1.7,1.8-alpha-SNAPSHOT)
>>>>>>> if
>>>>>>> they want to be precise. Or approximations:
> [1.7,1.8-a), [1.7,1.7.999]
>>>>>>> Or we need to create another notation and define its
> semantics
>>>>>>> precisely
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Hervé
>>>>>>>
>>>>>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit
> :
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>> I agree with Jesse.
>>>>>>>>
>>>>>>>> A version range like [1.7,1.8) should exclude any
> artifact that
>>>>>>>> starts
>>>>>>>> with 1.8
>>>>>>>>
>>>>>>>> Then maven (or aether) would respect semantic
> versioning rules.
>>>>>>>>
>>>>>>>> We use version ranges/semantic versioning and API
> analysis to ensure
>>>>>>>> our
>>>>>>>> artifacts are versioned correctly. Sometimes we get
> caught out by
>>>>>>>> what
>>>>>>>> Jesse outlined below.
>>>>>>>>
>>>>>>>> On 27/09/2012 15:51, Stephen Connolly wrote:
>>>>>>>>
>>>>>>>> On 27 September 2012 14:41, Jesse Long
> <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<http:/**/maven.apache.org/**users/**
>>>>>>>>>>
> getting-help.html<http://maven.apache.org/**users/getting-help.html>
>>>>>>>>>> >
>>>>>>>>>>
> <http:/**/maven.apache.org/**users/**getting-help.html<http://maven.apache.org/users/**getting-help.html>
>>>>>>>>>>
> <http**://maven.apache.org/users/**getting-help.html<http://maven.apache.org/users/getting-help.html>
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>> Jira issue MNG-3092, reported over 5 years
> ago, is related to this
>>>>>>>>>> issue,
>>>>>>>>>> but the initial report is for a similar
> issue, not this issue. The
>>>>>>>>>> issue
>>>>>>>>>> I
>>>>>>>>>> describe above is reported and discussed in
> the comments for
>>>>>>>>>> MNG-3092
>>>>>>>>>> though.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Jesse
>>>>>>>>>>
>>>>>>>>>>
> ------------------------------********------------------------**
>>>>>>>>>> --**--**
>>>>>>>>>> --**---------
>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> users-unsubscribe@maven.******apac**he.org
> <http://apache.org><
>>>>>>>>>> users-unsubscribe@**maven.**ap**ache.org
> <http://apache.org> <
>>>>>>>>>> http://maven.apache.org><
>>>>>>>>>>
>>>>>>>>>> users-unsubscribe@**maven.**apache.org
> <http://maven.apache.org><
>>>>>>>>>>
> users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org>
>>>>>>>>>> >
>>>>>>>>>> For additional commands, e-mail:
> users-h...@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
> ------------------------------******--------------------------**
>>>>>>>>>> --**
>>>>>>>>>>
>>>>>>>>> --**
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail:
> users-unsubscribe@maven.****apac**he.org<
>>>>>>>> http://apache.org**>
>>>>>>>> <users-unsubscribe@**maven.**apache.org
> <http://maven.apache.org><
>>>>>>>>
> users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org>
>>>>>>>> >
>>>>>>>> For additional commands, e-mail:
> users-h...@maven.apache.org
>>>>>>>>
>>>>>>>>
> ------------------------------******--------------------------**
>>>>>>>> --**
>>>>>>>>
>>>>>>> --**---------
>>>>>>> To unsubscribe, e-mail:
> users-unsubscribe@maven.****apac**he.org<
>>>>>>> http://apache.org**>
>>>>>>> <users-unsubscribe@**maven.**apache.org
> <http://maven.apache.org><
>>>>>>>
> users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org>
>>>>>>> >
>>>>>>> For additional commands, e-mail:
> users-h...@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
> ------------------------------******--------------------------**
>>>>>>> --**
>>>>>>>
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail:
> users-unsubscribe@maven.****apac**he.org<
>>>>>> http://apache.org**>
>>>>>> <users-unsubscribe@**maven.**apache.org
> <http://maven.apache.org><
>>>>>>
> users-unsubscribe@**maven.apache.org<users-unsubscr...@maven.apache.org>
>>>>>> >
>>>>>> For additional commands, e-mail:
> users-h...@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail:
> users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>>
> <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-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
