I - almost - disagree completely, I've successfully used ranges on seven separate commercial projects. A mix of sizes from corporate to startup.
If you care at all about agility being explicit everyone is very cumbersome, the fundamental aspect is determinism - meaning that its obvious WHY it behaves the way it does, once you understand how maven implements ranges its very easy to use to them to great effect. Having said that using ranges can be dangerous hence the composition pattern mentioned in my previous email. When you say nail down your version do you use [1.7.1] or 1.7.1? On Fri, Sep 28, 2012 at 11:20 AM, Baptiste MATHUS <m...@batmat.net> wrote: > +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 <stephen.alan.conno...@gmail.com> > > > 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> > > >>>>>>> > > > >>>>>>> > > >>>>>>> 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< > > 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.**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.**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 > > > > > > > > > > -- > > Baptiste <Batmat> MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > nbsp;! > > >
