Scala 3 guarantees backward compatibility between all releases and forward compatibility between patch releases in the same minor line. In the rest of this post, the term compatibility will always refer to output compatibility. Conversely, backward compatibility means that the newer compiler can use the output of the older version. We say that the two versions are forward compatible when the older compiler can depend on the output of the newer one. To be more precise, we will further subdivide output compatibility to forward and backward. It can be understood as an ability of one version of the compiler to use the output (binaries and TASTy files) generated by the other version of the compiler and understand it correctly. Output compatibility (sometimes called binary compatibility, especially in Scala 2 contexts) is much more tricky and essential for our long-term plans for Scala. That, however, will not affect projects depending on your code. In the worst-case scenario, you will be locked on one version of the compiler for some time. If your project is affected by a source-incompatible change, you often need to make only small adjustments. In the past, fixing those problems have usually been limited to specifying explicit types in some places where the programmer relied on type inference. In addition, breaking source compatibility is usually not a big deal, as it can easily be detected at compile-time. Moreover, after every release candidate, we are testing the compiler on practically all open-source projects that were ever published for Scala 3. To enforce that, we are running builds of hundreds of open-source Scala 3 projects every night. We put a lot of effort into ensuring that source compatibility is preserved between patch releases, and that every infringement between minor versions is easy to fix.

We say that two compiler versions are source compatible if every single project that can be compiled with one version can also be compiled with the other, and the resulting programs behave the same way. For Scala 3 compiler, compatibility involves two concepts: source and output compatibility. Let us examine the term compatibility closer right now. In the Scala world, the first intuition for this term could be phrased as follows: a new version of Scala is compatible with a previous version of Scala if a program that used to work with the earlier version still works with the latest version. The term compatibility is often used quite vaguely. What allows us to think in such a way is the compatibility guarantees. Nevertheless, we still treat all those versions as an implementation of the same language. Each has brought performance and stability enhancements, fixed bugs, improved reporting or introduced some new experimental features to the language. Since the initial release of Scala 3, there have been seven stable versions of the compiler. Soon, we will start releasing Long-Term Support versions of the compiler for the users that require enhanced stability.Ĭompilers, as all software really, are constantly evolving.After evaluation, we have dropped the experimental -scala-output-version flag, as it turned out to be too hard to maintain and potentially harmful to the ecosystem.We are using hundreds of real-life projects to test that. We are testing that the code that compiles with previous versions of the compiler will still compile in future releases, unless the fact that the code was compiling was a bug in the compiler.Also, you should upgrade to Scala 3.2 in your next minor release.

If you are maintaining a library, you should drop Scala 3.0.

You should not cross-compile between Scala 3 versions.

3.1.3 -> 3.2.0) requires the same considerations as changing the minor version of any other dependency, yet is generally advisable.

The Scala 3 version that you are using to compile your code should be treated the same way as any library dependency in your project.

Pterm version