[GitHub] [incubator-pekko] Kordyjan commented on issue #6: Upgrade Scala 3.x versions

["Kordyjan (via GitHub)" <gi...@apache.org>]

Kordyjan commented on issue #6:
URL: https://github.com/apache/incubator-pekko/issues/6#issuecomment-1495986140

   Some thoughts after reading the thread.
   
   ### Source compatibility and minor version
   
   First, I wanted to state that source compatibility has nothing to do with adding new features or naming a release as "minor". This may be counterintuitive, but upgrading from 3.2.1 to 3.2.2 has the same probability of breaking your code as upgrading from 3.2.2 to 3.3.0. And contrary to what many believe, that probability is small.
   
   Let me show you where source incompatibilities come from to see that better. I can think of three distinct sources of such incompatibilities:
   
   1. Changes to the type inference. This is the most common reason for problems. The entire inference system is interconnected, and changing it to work as expected in one example can cause other, more complex examples to start behaving unexpectedly. This is made worse by the fact that there may be no distinction between what is expected and what is not for complex cases, as different people can expect different types to be inferred. The good thing is, usually, to fix source incompatibility there, you only need to add explicit type ascription.
   2. Bugfixes. Sometimes the compiler has bugs causing an acceptance of incorrect code. For example, inline parameters are not stable references, but all compiler versions up to 3.2.2 were, by mistake, treating them as such. Many libraries were relying on that fact, and from their point of view, 3.3.0 will introduce a new source incompatibility, even though it will only prevent them from writing potentially unsound code. We do what we can to be clear about those changes in the release announcements and to offer possible workarounds.
   3. Intentional changes. I can only recall a single case of that happening since 3.0.0: [this PR](https://github.com/lampepfl/dotty/pull/14840).  It solved one infuriating source of problems, changing the meaning of a very specific, niche code. Before we do anything like that again, we will ensure that it has a negligible impact on open-source projects.
   This "checking of impact" takes the form of building the entire Scala 3 open-source ecosystem with our Open Community Build. You can read more about it [here](https://virtuslab.com/blog/prevent-scala3-compiler-regressions-community-build/) and [there](https://virtuslab.com/blog/how-to-be-a-part-of-scalas-open-community-build/). Thanks to that, we will know about any real-life source incompatibility in advance and, when possible, take steps to ensure that it will not be included in a stable release.
   
   I don't believe there is a reason to fear source-breaking changes now, as they are much less frequent than in the past and communicated in advance. Also, they can happen both in a patch and in minor releases.
   
   ### The language version as a dependency
   
   The notion that upgrading the compiler version is much more dangerous and unpredictable than upgrading the version of the library your project depends on stems from the fact that Scala 2 was not following semantic versioning. This is no longer the case.
   Moreover, there is an argument that bugs in the compiler may not manifest in your project but may be visible in downstream projects. While this is true, it is precisely the same as with the library you and your downstream projects depend on. It can introduce bugs that are not visible to you, but people depending on your library can start to have problems because you upgraded your dependency. The eviction mechanism kicks in, and now they unknowingly use a newer (bugged) version of a dependency. In the case of the compiler upgrade, there is no eviction, so every change needs to be made explicitly. This means that bumping the minor version of the compiler is even safer than bumping the minor version of any other library.
   
   ### Older versions and stability
   
   Sometimes, I see claims that older versions can be more dependable because they are more mature. This could be a case if they received any updates. Bugs found in 3.1.3 will never be fixed in any future 3.1 release because there will be no future 3.1 releases. Some of them were, however, fixed in 3.2.0. There was no significant redesign or rewrite between 3.1.3 and 3.2.0. This version could have been named 3.1.4 if it hadn't introduced any forward-incompatible (but still backward-compatible) changes. This means that 3.2.0 was more mature than 3.1.3, even though Scala 3.1 was there for a year, and Scala 3.2 was a new thing.
   
   In terms of stability and correctness, the newer version of the compiler will always be better than the older one. Of course, we need to keep in mind that we may change the minimum required version of the compiler for downstream projects, but this is the same consideration as with any other dependency.
   
   ### What about LTS?
   
   The LTS line (that is 3.3) will be different than previous versions. Even though we will release 3.4 soon, 3.3 will still receive backward and forward-compatible patch releases for at least 3 years, possibly longer. Of course, we will keep our guarantee that all projects compiled with any version of 3.3 can be used as a dependency for projects compiled with any version of the compiler newer than and including 3.3.0.
   
   This is why I think the newest 3.3 version at the moment of release would be the best compiler version for Pekko. For the time being, I encourage you to use 3.3.0-RC3 for development and, later, 3.3.0-RC4 - which comes out next week.
   
   3.3.0-RC3 is stable. lichess.org is even using it in production. We need another RC because the linter still has some unsolved problems. Even though we have been pushing this release a few times already, we are confident that the stable 3.3.0 will be out before the end of April.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org
For additional commands, e-mail: notifications-help@pekko.apache.org