Add info about percentage of libraries affected by source incompatibi…

…lities in 3.2
scala · Aug 17, 2022 · 86bc96d · 86bc96d
1 parent 1b5147c
commit 86bc96d
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 3 deletions.
diff --git a/blog/_posts/2022-04-12-scala-3.1.2-released.md b/blog/_posts/2022-04-12-scala-3.1.2-released.md
@@ -9,7 +9,7 @@ We are happy to announce the release of Scala 3.1.2. This new release brings a f
 
 ## Configurable Scala output version
 
-**August 2022 Update:** configurable Scala output version turned out to be really hard to maintain and is not solving some of problems it was intended to solve. We have decided to drop it in 3.2 and propose long term support versions instead. You can read more in [the dedicated post]({{ site.baseurl }}/blog/2022/08/05/long-term-compatibility-plans.html).
+**August 2022 Update:** configurable Scala output version turned out to be really hard to maintain and is not solving some of problems it was intended to solve. We have decided to drop it in 3.2 and propose long term support versions instead. You can read more in [the dedicated post]({{ site.baseurl }}/blog/2022/08/17/long-term-compatibility-plans.html).
 
 First and foremost, after months of brainstorming and testing, we are bringing an experimental possibility to configure the Scala output version. This means that the compiler can now generate TASTy files and classfiles in a format used by an older minor version of Scala (which can currently be only 3.0.x) effectively specifying the minimum version of the compiler that is able to read your compiled code.
 

diff --git a/...22-08-05-long-term-compatibility-plans.md → ...22-08-17-long-term-compatibility-plans.md b/...22-08-05-long-term-compatibility-plans.md → ...22-08-17-long-term-compatibility-plans.md
@@ -36,8 +36,7 @@ We believe that you should treat the compiler as one of your dependencies. If yo
 
 If you are a library author following the semantic versioning, we advise you to introduce new minor versions of the compiler only in minor releases of your library. New patch versions of the compiler can be introduced anytime, as they are forward and backward compatible.
 
-That may be surprising if you have experience developing libraries for Scala 2. For example, migrating any codebase from 2.11 to 2.12 was a huge undertaking. Since they were not output-compatible, most libraries needed to resort to cross-compilation to support both versions. Thanks to the guarantees of Scala 3, there is no longer a need for cross-compilation. For example, the migration from Scala 3.1 to Scala 3.2 for the large majority of the projects would only require changing the version in the build definition.
-// TODO: PUT HERE THE EXACT PERCENTAGE OF PROJECTS THAT WILL BE AFFECTED BY THE SOURCE INCOMPATIBILITIES BETWEEN 3.1 AND 3.2
+That may be surprising if you have experience developing libraries for Scala 2. For example, migrating any codebase from 2.11 to 2.12 was a huge undertaking. Since they were not output-compatible, most libraries needed to resort to cross-compilation to support both versions. Thanks to the guarantees of Scala 3, there is no longer a need for cross-compilation. For example, the migration from Scala 3.1 to Scala 3.2 for the large majority of the projects would only require changing the version in the build definition. We have tested 900 Scala libraries that were passing compilation using 3.1.3. Out of them, only 13 failed to compile with 3.2.0. That means that for 98.6% of the libraries bumping the compiler version to 3.2.0 does not require a single change in the source code.
 
 ## The problem