Question about changes in the Scalac release cycle

Compiler
11

An argument in favor of forward bincompat is that it simplifies the life of sbt plugin maintainers and users. If Scala doesn’t promise forward bincompat from now on, then plugin maintainers will be forced to compile with the minor Scala version sbt is compiled with. If a plugin is compiled with Scala 2.12.3 and sbt is still stuck with 2.12.1, sbt could fail to load the plugin if the plugin uses a new method that was added in scala-library 2.12.3.

This is not an isolated example. It would also disrupt the compiler plugins and macro libraries’ ecosystem. Most of the plugins and macro libraries do not cross-compile to the full Scala version, but the partial one. If a user adds a version of a compiler plugin that was compiled with 2.12.3 to a project that still uses 2.12.0, compilation could also fail.

There are solutions to these problems. The first one that comes to mind is to let our tools force a consistent use of Scala versions. For example, sbt would force modules with sbtPlugin := true to compile with a Scala version lower or equals to the Scala version that the plugin’s sbt uses. To make a plugin compile with the newest Scala version, sbt plugin maintainers would need to update their sbt.version in project/build.properties. A similar solution could be applied for the builds of compiler plugins and macro libraries: if they don’t cross-compile to the Scala full version, sbt would fail.

This is not a complete solution, though:

  • Developers stuck on outdated tools will not get these checks.
  • Developers need to become familiar with the new semantics and know how to act on the errors.

But, despite these problems, I think the Scala community would be much better off without forward bincompat because:

  • Both scala-library and compiler maintainers would be able to ship things much faster. For example, @oscar’s addition of substitute methods to <:< and =:= was merged into 2.13.x instead of 2.12.3 because of a breakage of forward binary compatibility.
  • New features and improvements to the compiler that have to wait because they require changes to scala-reflect would be possible.
  • API additions to the scala-library would not need to wait until the next major version.

All these together make major versions lighter in features (easing migration). IMO, the most important observation is that it would allow the Scala team to release major versions much less often.

In my book, the cost of forward bincompat is too high. For the moment, I believe it’s better to remove it.

1 Like