Skip to content

Commit 0ec885b

Browse files
Kordyjanbishabosha
andauthored
Update blog/_posts/2022-08-05-long-term-compatibility-plans.md
Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com>
1 parent d4abc91 commit 0ec885b

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

blog/_posts/2022-08-05-long-term-compatibility-plans.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,7 +22,7 @@ The term *compatibility* is usually used quite vaguely. In the Scala world, the
2222

2323
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. We put a lot of effort into ensuring that source compatibility is preserved between the patch releases, and every infringement between minor versions is easy to fix. To enforce that, we are running builds of hundred of open-source Scala 3 projects every night. Moreover, after every release candidate, we are testing the compiler on practically all open-source projects that were ever published for Scala 3.
2424

25-
Also, it is worth noting that braking source compatibility is usually not a big deal, as it can be easily detected at compile time. Fixing those problems in the past usually only involved specifying explicit types in some places where the programmer used type inference. If your project is affected by breakage in the source compatibility, you often need to make only small adjustments. In the worst-case scenario, you will be locked on one version of the compiler for some time. That, however, will not affect projects depending on your code.
25+
Also, it is worth noting that breaking source compatibility is usually not a big deal, as it can be easily detected at compile time. Fixing those problems in the past usually only involved specifying explicit types in some places where the programmer used type inference. If your project is affected by breakage in the source compatibility, you often need to make only small adjustments. In the worst-case scenario, you will be locked on one version of the compiler for some time. That, however, will not affect projects depending on your code.
2626

2727
Output compatibility (sometimes called *binary compatibility*, especially in Scala 2 contexts) is much more tricky and essential for our long-term plans for Scala. In the rest of this post, the term *compatibility* will always refer to output compatibility. We can say that compiler `A` is output compatible with compiler `B` when compiler `B` can use the output (binaries and TASTy files) generated by compiler `A` and understands it correctly.
2828

0 commit comments

Comments
 (0)