I thought about mathematical ranges as well, and the outcome for me personally that a strict mathematical time vector interpretation makes no sense for maven.
You have a library in version 1.7.0 which fits your project. Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary incompatible change. But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. Also: for most dependencies you only like to get released versions via your version range. But as I read here some use this internally as well and like to get SNAPSHOTS resolved. What about simply writing up what people like to have and then implement a new mechanism? I could even think about regexp based versioning... LieGrue, strub ----- Original Message ----- > From: Hervé BOUTEMY <herve.bout...@free.fr> > To: Maven Users List <users@maven.apache.org> > Cc: > Sent: Saturday, September 29, 2012 5:06 AM > Subject: Re: Version ranges not working > > yes, https://jira.codehaus.org/browse/MNG-3092 is still here > > I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we > do > so, it's not a *range* any more but a range + a filter > (1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english") > > and actual discussion helps me dig into other ideas that could be useful: > IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and > beta too, no? > But I'm not sure about the use case (and "Guide to using version > ranges" still > needs to be written: https://jira.codehaus.org/browse/MNG-1368) > I understand that when a library is at 1.9 and someone needs old 1.8-, he > implictely wants releases, not alpha nor SNAPSHOTS > But if 1.8 is still not out, and there is still work on 1.7.x, we need to > accept *latest* 1.7.x whatever its maturity level is > > > Really , excluding version from a mathematical range is another operation > that > needs some specification and probably something more expressive than [min,max] > > Regards, > > Hervé > > Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit : >> I find this topic interesting for a couple of reasons. I was one of the >> original posters of this topic and created some of the relevant JIRA issues >> regarding it. >> >> However one of the problems is that since this issue was never fixed...and >> sadly seems never will be...we had to abandon the use of version ranges. I >> do not agree they are a bad idea. I think they could have been a very >> useful feature if implemented as originally proposed. >> (The fundamental problem was that they did not exclude SNAPSHOTS as >> originally intended/stated.) >> >> Effectively we had to work around the lack of version ranges by just >> building against SNAPSHOTS instead (I'm talking about internal code > here). >> So effectively the SNAPSHOT became our version range. One of the problems >> of this approach is now I have to toggle between going offline/online if I >> don't want to accept new updates since it will be changing on a regular >> basis. Using version ranges would have been a more elegant solution as it >> would give me more control over what versions I depend on during >> development. >> >> Because it wasn't fixed and we had to do the workaround I have not been >> close to this issue anymore...its been like 5 years or more. But the short >> answer is it should be fixed and it can/could be useful as some have >> indicated in this discussion. >> >> -Dave >> >> On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler > <rwhee...@artifact-software.com >> > wrote: >> > >> > On 28/09/2012 3:17 AM, Jesse Long wrote: >> >> Without version ranges, how do I write a library that works with > SLF4J >> >> version 1.5.*, but does not work with SLF4J 1.6.*? >> >> >> >> Do I depend on, say, version 1.5.11? Then when a user depends on > my >> >> library, and on slf4j-api directly, specifying slf4j-api version > 1.6.0 in >> >> his pom, Maven will link in 1.6.0. So that is pretty useless to > me. If I >> >> find a way to enforce version 1.5.11. Then I am loosing the > ability to >> >> upgrade to any future version 1.5.*. >> >> >> >> I am not sure how version ranges will help you in this case. >> > >> > Your mythical user is overriding your version 1.5.* with 1.6.* so he > will >> > be in trouble using your library regardless of what you put in your >> > dependency. >> > >> > If your library is clearly documented as not being compatible with >> > versions after 1.5.*, then the user is responsible for making sure > that >> > nothing brings in a later version of slf4j. >> > >> > You had better write a big note about your restriction since most of > us >> > will just put an exclusion on your transitive dependency for slf4j > and >> > run >> > with the version that we want. >> > >> > There are not many good libraries that are not upwards compatible and > it >> > is generally safe to run with the latest version of everything. >> > The good library authors will change the artifact name if the new > version >> > is not capable of supporting code written for the previous version. >> > >> > I have yet to see a good case for version ranges and it seems that > they >> > cause these sort of discussions every year or so. >> > >> > Ron >> > >> > Cheers, >> > >> >> Jesse >> >> >> >> On 28/09/2012 01:20, Baptiste MATHUS 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<http://www.sonatype.com/pe >> >>> > ople/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 >> >> >> >> > ------------------------------**------------------------------**--------- >> >> To unsubscribe, e-mail: >> >> > users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> >> >> For additional commands, e-mail: users-h...@maven.apache.org >> > >> > -- >> > Ron Wheeler >> > President >> > Artifact Software Inc >> > email: rwhee...@artifact-software.com >> > skype: ronaldmwheeler >> > phone: 866-970-2435, ext 102 >> > >> > >> > > ------------------------------**------------------------------**--------- >> > 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
