Skip to content

Commit d2117c8

Browse files
committed
Add links to spec
1 parent fa10f0b commit d2117c8

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

blog/_posts/2022-01-31-scala-3.1.1-released.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -34,15 +34,15 @@ Together with 3.1.1 we have released the first RC version of the next patch rele
3434

3535
Scala 3 has excellent backward compatibility guarantees between the minor versions. Right now, that means that code compiled with Scala 3.1 can depend on libraries published with 3.0 without any problems. The opposite, hovewer, is not true. Code compiled with 3.0 is not able to read dependencies compiled with 3.1. After the recent release of Scala 3.1.0, we can see that libraries should be really cautious with updating the compiler version, as it forces a bump on every user of that library. We do not want library authors to be stuck on old versions of the compiler as that would mean that they are locked out of many bugfixes, or we would need to spend enormous effort on backporting every bugfix to all past versioning lines.
3636

37-
We are sure we want to mitigate those difficulties. We already have implemented the first and most important part of the solution and have it ready for public testing. Beginning with Scala 3.1.2-RC1 the compiler is able to generate outputs that can be consumed by its older versions. To enable that, you need to specify the minimal targeted minor language version by using the experimental `-Yscala-release` flag.
37+
Our current plan to mitigate those difficulties is described in [the contributors discussion](https://contributors.scala-lang.org/t/improving-scala-3-forward-compatibility/5298), where you are free to leave your feedback. We already have implemented the first and most important part of the solution and have it ready for public testing. Beginning with Scala 3.1.2-RC1 the compiler is able to generate outputs that can be consumed by its older versions. To enable that, you need to specify the minimal targeted minor language version by using the experimental `-Yscala-release` flag.
3838

3939
We expect that in the future authors will use the newest available version of the compiler with `-Yscala-release` set to the lowest language version that support all features they need. This way they will be able to benefit from all the bugfixes without restricting their potential audience.
4040

4141
So, for example, compiling your library using Scala 3.1.2-RC2 with `-Yscala-release:3.0` flag, you make it possible for people still using Scala 3.0 to depend on your library. This has one limitation, you won't be able to use any symbol added to the standard library after 3.0. They are marked in the code and in the documentation by the `@since` annotation that was also added in this version.
4242

4343
One important note is that the `-Yscala-release` flag is experimental and not yet available in any stable release of the compiler. It means the build tools, such as SBT or Mill, are not yet aware of its existence. Of course, you can declare usage of the flag in your build file, and the compiler will respect it. However, there may still be some hiccups, like generated artifacts depending on the incorrect version of the stdlib. We will do our best to help fix those minor issues before the stable release of 3.1.2.
4444

45-
You can read about potential next steps and leave your feedback in [the discussion](https://contributors.scala-lang.org/t/improving-scala-3-forward-compatibility/5298) that initiated this change.
45+
Detailed description of the new flag can be found in [the reference page for the binary comaptibility](https://docs.scala-lang.org/scala3/reference/language-versions/binary-compatibility.html).
4646

4747
If you are interested in other changes brought by 3.1.2-RC1, there is, as always, [a changelog on GitHub](https://github.com/lampepfl/dotty/releases/tag/3.1.2-RC1).
4848

0 commit comments

Comments
 (0)