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

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

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

   Thanks for taking the time to write this comprehensive response, @Kordyjan!
   
   A few comments:
   
   > I don't believe there is a reason to fear source-breaking changes now, as they are much less frequent than in the past
   
   That's probably true especially in the future. In the past, there were many (mostly minor) source compatibility issues between Scala 3 versions, so I am somewhat careful about these statements.
   
   > In the case of the compiler upgrade, there is no eviction, so every change needs to be made explicitly.
   
   You can see that both ways. No eviction means, a user of a library compiled with a newer version will instead get compiler errors like these:
   
   ```
   class file ... is broken, reading aborted with class dotty.tools.tasty.UnpickleException
   [error] TASTy signature has wrong version.
   [error]  expected: {majorVersion: 28, minorVersion: 1}
   [error]  found   : {majorVersion: 28, minorVersion: 2}
   [error] 
   [error] This TASTy file was produced by a more recent, forwards incompatible release.
   [error] To read this TASTy file, please upgrade your tooling.
   [error] The TASTy file was produced by Scala 3.2.1.
   ```
   
   That's not necessarily better than eviction, especially when you have multiple dependencies built with different versions of the Scala compiler and then need to figure out where to go based on those error messages.
   
   > The LTS line (that is 3.3)
   
   I would imagine that all these problems mostly go away when everyone adopts 3.3.x. We will see if the situation will be vastly better than with Scala 2. At least you will be able to use "old" 3.3 artifacts when you start to adopt 3.4 for any of the new features. Realistically, library authors will have to stay on 3.3 for as long as possible.
   
   (Besides, note, how the compatibility benefits of the LTS version are not a technical feature but a feature of the promise of stability and its execution.)
   
   Supporting 3.4 or later features in parts of your codebase will be somewhat hard. We will see how that will play out when the ecosystem has to move to the next LTS version after 3.3. With the current cross-versioning scheme (`_3`) that will mix partly incompatible versions into the same namespace, I can foresee some issues... Fortunately, that will be a long time away.
   
   > lichess.org is even using it in production. We need another RC because the linter still has some unsolved problems.
   
   It's crucial to understand that an application has vastly different requirements than a library. You can always run the test suite for your application to ensure that your application runs fine on a new version. Library authors cannot completely predict how their library is used and what constraints and problems the users will have. Therefore, the hard-learned conclusion is to be very conservative about adopting new versions of any transitive dependency and not pull transitive dependencies to higher versions than necessary for minor reasons.
   
   In summary, I agree 3.3 LTS is great and we should definitely make sure that our binaries work with it and eventually move to it ourselves.


-- 
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