Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit : > 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. a range tells about a constraint then choosing a precise version between the multiple choices that match constraints is not about the range but about what is usually called "conflict resolution" This term is ok when it's about changing preferred version (ie when versions are not defined as range but as simple version, which means preferred version) but that term doesn't show that when it's about ranges, it's not about conflict but about choosing one version between the multiple valid choices: do you prefer the most recent? even if it is a snapshot or an alpha? or if the most recent is an alpha, you prefer to stick with stable version? IMHO, during development, you can want to test latest alpha SNAPSHOT, but when doing a release, you'll prefer stable versions
> > What about simply writing up what people like to have and then implement a > new mechanism? I could even think about regexp based versioning... sure, there is something to create here, but IMHO not into version ranges: into conflict resolution specification and switch (with CLI or IDE) > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
