Use lower bound when a version range with lower and upper bound is specified

[pweisenburger]

Following the discussion in #2954, it was decided that it makes sense for SBT to use the lower bound
in case multiple version candidates are found. This was implemented in #2959 and sbt/librarymanagement#80.

The current implementation picks the lower bound of a version range if there is no specified upper bound (e.g., [2.4,)). However, it does not seem to pick the lower bound if there is a specified upper bound (e.g., [2.4,3.0)), which should probably also be the case.

Further, some test cases also look like the version range is converted to its upper bound, which I'm not sure is correct but could be.

Tested with SBT 1.1.0

Use case

Assuming you have a library that depends on Akka 2.4. So when using the library in another project, the Akka dependency should be transitively resolved. Since all 2.x versions following Akka 2.4 will be binary-compatible, it would be nice to define the dependency as "com.typesafe.akka" %% "akka-actor" % "[2.4,3.0)" (so SBT does not issue dependency incompatibility warnings). However, this will keep downloading the latest version (even if a compatible version is locally cached) and, more importantly, it will also download RC versions (which is usually not what you want).

[eed3si9n]

Do you have a repro project that we can use for testing?

[pweisenburger]

There is currently no public repo, but if you just use this as an build.sbt file:

scalaVersion := "2.12.4"
libraryDependencies += "com.typesafe.akka" %% "akka-actor" % "[2.4,3.0)"

Doing an sbt compile, SBT 1.1 will check online and download the latest version (in this case Akka Actors 2.5.11).
 

One thing that might be related (not sure):

Using something like:

scalaVersion := "2.12.4"
libraryDependencies ++= Seq(
  "com.typesafe.akka" %% "akka-stream" % "2.4.20",
  "com.typesafe.akka" %% "akka-actor" % "[2.4,3.0)")

Akka Stream 2.4.20 depends on Akka Actors 2.4.20 (which is supported by the version range), but SBT resolves Akka Actors 2.5.11 (not sure if this is intended). In that specific case, it's easy to fix, but if you have a project, which explicitly depends on "2.4.20" and depends on library, which transitively depends on "[2.4,3.0)", SBT could resolve the 2.4.20 dependency satisfying all constraints (but it seems it resolves to 2.5.11 issuing eviction warnings).