yes, that's my point: ranges are the same, but version to choose are different
the solution won't come from ranges tweak but conflict resolution improvements Le samedi 29 septembre 2012 17:31:29 Stephen Connolly a écrit : > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
