+1. Version ranges are basically just a bad practice in my experience. I mostly don't see any interest apart from being able to see a normally passing build suddenly going rogue because you somehow had a dependency update somewhere in the dependency tree. (I wrote something similar in that comment http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577 )
So, please, Maven users, don't use them. It's like having scripts inside your pom.xml, it might seem sexy and powerful, but it's dangerous. Nail down a version, and upgrade explicitly when you need to and/or are ready to. You'll be very happy that way and your build'll stay green. Cheers 2012/9/28 Stephen Connolly <[email protected]> > 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] > > > > > > -- > Baptiste <Batmat> MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > nbsp;! >
