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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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> >>>>>>> > >>>>>>> >>>>>>> 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.**apache.org <http://maven.apache.org>< >>>>>>> users-unsubscribe@**maven.apache.org<[email protected]> >>>>>>> > >>>>>>> >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> ------------------------------****----------------------------** >>>>>> --** >>>>>> >>>>> --------- >>>>> To unsubscribe, e-mail: >>>>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>>>> <users-unsubscribe@**maven.apache.org<[email protected]> >>>>> > >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> ------------------------------****----------------------------** >>>> --**--------- >>>> To unsubscribe, e-mail: >>>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>>> <users-unsubscribe@**maven.apache.org<[email protected]> >>>> > >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>> <users-unsubscribe@**maven.apache.org<[email protected]> >>> > >>> For additional commands, e-mail: [email protected] >>> >>> >>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
