Version switch operator (++) doesn't work as expected on Scala 3

[ruippeixotog]

steps

Consider the following sample project on sbt 1.6.2:

// build.sbt

scalaVersion := "2.12.16"

lazy val core = project
  .settings(
    crossScalaVersions := Seq("2.12.16", "3.0.2", "3.1.2")
  )

lazy val subproj = project
  .dependsOn(core)
  .settings(
    crossScalaVersions := Seq("2.12.16", "3.1.2"),
    // a random library compiled against Scala 3.1
    libraryDependencies += "org.http4s" %% "http4s-core" % "0.23.12"
  )

// subproj/src/main/scala/Main.scala

import org.http4s.Uri

object Main extends App {
  // Just using something from http4s 
  println(Uri.fromString("example.com"))
}

Try running sbt "++3.0.2 compile".

problem

The compilation fails as sbt tries to build subproj.

expectation

I didn't expect ++3.0.2 to compile subproj, since it doesn't include a 3.0.x version in its cross-versions. In general, subprojects declaring Scala 3.1 as their Scala version can't be expected to compile successfully against Scala 3.0.x versions.

notes

This is an important use case for module-based projects like PureConfig. We want to compile PureConfig modules against the minimum possible Scala version to ensure maximum compatibility and we rely on ++ on CI and on our automated publishing process.

[eed3si9n]

@ruippeixotog Thanks for the report. Your expectations matches mine.

[eed3si9n]

Now that glob based fuzzy matching was contributed in https://github.com//pull/6894, I think we should retire the undocumented binary compatible matching from all Scala versions.

[ruippeixotog]

Hi @eed3si9n, I commented on the #6926. I'm still a bit confused on the application of fuzzy search for this case.

[eed3si9n]

I was having a conversation with someone regarding the two ++ changes in 1.7.0, and I am now thinking I was right 6 days ago:

Now that glob based fuzzy matching was contributed in #6894, I think we should retire the undocumented binary compatible matching from all Scala versions.

One aspect of 1.7.0 fuzzy matching is that it doesn't check for either backward or forward compatibility, and it only requires that the pattern matches a single Scala version out of crossScalaVersion. If we consider 2.12.15 to be an example of fuzzy pattern, it will fail because 2.12.15 doesn't exist in the crossScalaVersion list. 1.7.0-RC1 is not implemented that way, but I think that would be a far simpler behavior to explain instead of silently upgrading or downgrading Scala version different from build.sbt.

This will also fix the ++3.0.2 compile problem because only core subproject lists 3.0.2.