The hasn’t been a forum thread about SIP-51 (Drop Forwards Binary Compatibility of the Scala 2.13 Standard Library) so far, so here it is.
I’m not going to repeat what’s in the SIP but I can share a couple of thoughts about implications.
First of all, the proposed behavior can be tested out in current sbt using the following settings:
// Update scala-library on the dependencyClasspath according to the dependency tree, // instead of keeping it pinned to the scalaVersion. scalaModuleInfo := scalaModuleInfo.value.map(_.withOverrideScalaVersion(false)), // When invoking the scala compiler, prevent zinc from setting `-bootclasspath scala-library.jar` // (with the scala-library of scalaVersion). // Instead, include the scala-library from the dependencyClasspath in the ordinary `-classpath`. classpathOptions := classpathOptions.value.withAutoBoot(false).withFilterLibrary(false), // Running an application through sbt does not fork, it uses a custom class loader within the // JVM of sbt. By default, this class loader uses the scala-library according to scalaVersion. // https://www.scala-sbt.org/1.x/docs/In-Process-Classloaders.html classLoaderLayeringStrategy := ClassLoaderLayeringStrategy.Flat,
sbt will then update the standard library according to the dependency tree. The Scala compiler version remains unchanged and is defined by
scalaVersion. I believe this is how the change should be implemented, we want to leave users in control of the Scala compiler version.
As shown in the SIP, there is a way that users can experience a failure after we implement this change. When a new verison of a library L starts using new scala-library API and someone updates to that version of L while remaining on an old sbt, the scala-library on the classpath stays according to the user’s
scalaVersion and may be missing the new API. This can result in compile-time and run-time errors.
I think it’s not possible to check for this and show an early warning or error to the user.
- We can encourage library authors to write in their release notes that users need to upgrade sbt
- There could be a cooldown period between the sbt release that implements the change and the first Scala 2.13 release which actually takes advantage of it (i.e., breaks forwards binary compatibility).