This is a friendly reminder about SIP-51, a proposal to drop forward compatibility in Scala 2.13.x and discussion thread going on in the Contributors forum.
Traditionally scala-library on Scala 2.13.x has kept both backward and forward compatibility, so sbt and rules_scala could basically hardcode the scala-library version to the exact patch version the build user has specified. If SIP-51 is accepted, and a new Scala 2.13.x ships, it could potentially add new methods so not using the max scala-library patch version may result in a linkage error. Two potential routes we are considering for sbt are:
automatically update scala-library version to max patch, i.e. scala-library would be treated as "a normal library"
fail the build when the dependency graph finds scala-library greater than scalaVersion
In general, it might be useful to hear from Bazel users in a thread like the one for SIP-51, since most who work on Scala itself do not have good feel on how things are done with Bazel + rules_scala.
This is a friendly reminder about SIP-51, a proposal to drop forward compatibility in Scala 2.13.x and discussion thread going on in the Contributors forum.
Traditionally scala-library on Scala 2.13.x has kept both backward and forward compatibility, so sbt and rules_scala could basically hardcode the scala-library version to the exact patch version the build user has specified. If SIP-51 is accepted, and a new Scala 2.13.x ships, it could potentially add new methods so not using the max scala-library patch version may result in a linkage error. Two potential routes we are considering for sbt are:
scalaVersionIn general, it might be useful to hear from Bazel users in a thread like the one for SIP-51, since most who work on Scala itself do not have good feel on how things are done with Bazel + rules_scala.