"Anything else than pure numbers is a candidate to be broken somehow." yes
Maven defines some qualifiers: see [1] for exact list (notice the synonyms, even for the release, that can be "ga" or "final") I chose the qualifiers from what I could see that didn't have multiple interpretations: yes, MR is not a good candidate Even the "a" and "b" qualifiers, which are actually synonyms for "alpha" and "beta", are sometimes used for maintenance release: well known example is javax.transaction 1.0.1B which is not a beta but maintenance release But the choice was to ignore such exceptions and support "a" and "b" for alpha and beta shortcuts Regards, Hervé [1] http://maven.apache.org/ref/3.0.4/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html Le vendredi 28 septembre 2012 09:09:19 Mark Struberg a écrit : > 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.o > > rg/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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
