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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
