Adding Akka's ByteString as a Scala module and/or stdlib

Scala Platform
9

Another option is to drop the forwards compatibility requirement for the Scala 2.13 standard library.

Today, the org.scala-lang::scala-library library is treated specially by sbt, its version is always pinned to the scalaVersion used in the project.

For other dependencies, sbt automatically picks the newest version of a library required by the depdency graph. For example, with

libraryDependencies ++= List(
  "com.softwaremill.sttp.client3" %% "core" % "3.8.3", // depends on ws 1.3.10
  "com.softwaremill.sttp.shared"  %% "ws"   % "1.3.9", // for demonstration
)

sbt uses version 1.3.10 for ws. This means that libraries only needs to maintain backwards binary compatibility. A new class in ws 1.3.10 doesn’t break code that was compiled against 1.3.9, and sbt makes sure the newest required version is used.

Because this is not the case for scala-library, we cannot add anything to the standard library, we have to maintain forwards and backwards binary compatibility.

The difficulty with this change is that it can only be rolled out in new versions of sbt. If

  • Scala 2.13.11 is not forwards compatible with 2.13.10
  • a user upgrades a dependency that was built with 2.13.11
  • does not upgrade sbt
  • and keeps the project’s scalaVersion to 2.13.10

they can run into linkage errors at runtime.

sbt would only upgrade the scala-library, but not the Scala compiler used in the project. This would not cause any problems, the Scala 2.13.10 compiler works fine with the 2.13.11 standard library.

I’m interested to hear what people think about this.

Does mill (and other build tools) have the same special treatment for scala-library?

2 Likes