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 <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>
>>>>>
>>>>> 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
>
--
The best argument for celibacy is that the clergy will sooner or later
become extinct.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
