The issue I see is that there is a difference with ranges between build time and run time.
In general at build time you want the lowest version in the range (assuming the api is versions correctly) to ensure you are compatible with the smallest set of api method signatures. At run time you want the highest as it has the most big fixes in theory. At test time you ideally want every version. But that matrixes out to an impossible combinatorial. On Saturday, 29 September 2012, Hervé BOUTEMY wrote: > 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 > > > > > >> >>
