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
