So I just made a draft PR that updates the Scala 3 version in Pekko to 3.3-RC3 (see https://github.com/apache/incubator-pekko/pull/270) and aside from one change, there hasn't been any significant source changes. In fact almost all of the changes were due to Scala 3.3's improvements in warning in cases (such as unchecked) which isn't anything specific to Scala 3.3 (i.e. see https://github.com/apache/incubator-pekko-projection/pull/17 which also required similar changes due to having to upgrade to latest 2.13 version).
On Fri, Mar 24, 2023 at 1:37 PM Nicolas Vollmar <nvoll...@gmail.com> wrote: > I was talking about compiling Pekko. We already can't solve deprecation > warnings from Scala 2.13 due to source compatibility for compiling with > Scala 2.12. > As Scala 3 continues to deprecate and remove old syntax we'll continue to > run into issues keeping Scala 2.12 compiling. > > On Fri, 24 Mar 2023 at 13:32, Matthew Benedict de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > One precondition to upgrade to newer versions of Scala 3 would be > > dropping > > support for Scala 2.12. > > Scala 2.13 at least has support for some of the Scala 3 Syntax with > > compiler flags to cross compile. > > > > Are you talking about support on artifact level or on syntax level? Afaik > > there isn't any plan for Scala 3.3 to drop support for Scala 2.13 > artifacts > > (artifacts are completely separated from supported syntax). If we are > > talking about a hypothetical Scala 3 user of Pekko, the Scala3 syntax > that > > Pekko happens to use will be irrelevant here. In other words, if a user > is > > upgrading from Scala 3.1/Scala 3.2 to Scala 3.3 then they will have to > > upgrade the syntax of the source code irrespective of Pekko. If we are > > talking about difficulties of cross compiling for Scala 3/Scala 2 within > > Pekko itself I think we would have to see if there are any syntax > breaking > > changes in this regard (I didn't see any for Scala 3.3 but I may have > > missed something). Since an RC for Scala 3.3 is out we can pretty easily > > figure out if this is going to be a problem right now. > > > > I think what Johannes said here is important, which is that currently > there > > aren't any users of Pekko Scala 3 and because of this we really shouldn't > > overthink it. And even then, if we do release Pekko with Scala 3.3 and > some > > hypothetical user is going to have problems because they haven't upgrade > to > > Scala 3.3 yet, they can easily use the Pekko Scala 2.13 artifact and > since > > we are not using any bespoke Scala 3 features in Pekko currently on a > > source level the user is actually not going to notice any difference. > > > > On Fri, Mar 24, 2023 at 1:18 PM Nicolas Vollmar <nvoll...@gmail.com> > > wrote: > > > > > IMHO we should use the lowest supported version of Scala 3 to not force > > > user to upgrade to newer versions. > > > > > > Scala 3 continues to deprecate old syntax. Some of it will produce > > warnings > > > in Scala 3.2 and may be removed in 3.3 or later. > > > For example > > > > > > https://dotty.epfl.ch/docs/reference/dropped-features/package-objects.html > > > or https://dotty.epfl.ch/docs/reference/changed-features/imports.html > > > > > > One precondition to upgrade to newer versions of Scala 3 would be > > dropping > > > support for Scala 2.12. > > > Scala 2.13 at least has support for some of the Scala 3 Syntax with > > > compiler flags to cross compile. > > > > > > > > > > > > On Fri, 24 Mar 2023 at 10:26, Matthew Benedict de Detrich > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > So some discussions on github are popping up regarding which Scala 3 > > > > version we should pick so I think it's time to discuss this formally > on > > > the > > > > mailing list. > > > > > > > > As a precursor one thing people need to understand is that the Scala > 3 > > > > release cycle has changed, quoting from > > > > > > > > > > https://github.com/apache/incubator-pekko/issues/6#issuecomment-1302701657 > > > > > > > > > Scala 2 used epoch.major.minor version convention. Scala 3 has > > > > major.minor.patch. > > > > > > > > > So there is no 3.0/3.1/3.2/etc cross-compilation - the assumption > is > > > > that: > > > > > > > > > * you can compile against the same minor version with backward- and > > > > forward-compatibility: 3.1.3 dependency against 3.1.0 code, 3.0.0 > > > > dependency against 3.0.1 code, etc > > > > > * within the same major version you always have > > backward-compatibility: > > > > 3.1.3 dependency can be used in 3.1.3 project, but also 3.2.0 project > > and > > > > in future against 3.3.0 project > > > > > > > > This means that if we pick a Scala version, we are essentially > forcing > > > the > > > > potential Scala 3 users of Pekko to bump their Scala 3 version to the > > > minor > > > > that we decide on. On surface value this means that we should pick > the > > > > lowest Scala 3 minor version that we can support however there is the > > > fact > > > > that Scala 3.3 is going to come out soon which will be an LTS > release. > > > The > > > > LTS release means that if any bugs are found after Scala 3.3 for a > > period > > > > of 2 years, they will be backported to Scala 3.3. The big advantage > > this > > > > brings us, is that it allows us to freely bump Scala 3.3 without > > breaking > > > > our users if any potential bugs are found in the future. If we decide > > to > > > > stick with Scala 3.2 or 3.1 and some bug is found in Scala 3 later on > > > that > > > > affects us, we will have to update to a version of Scala 3 that will > > > break > > > > binary compatibility. This facet is of even more importance when > > > > considering our 1.0.x release branches, which are designed to never > > break > > > > binary/backwards compatibility, i.e. if we do 1.0.x releases with > Scala > > > > 3.1/3.2 and some critical bug/CVE comes out later we could > potentially > > be > > > > forced to update the minor version which would break this > > > binary/backwards > > > > compatibility, this wouldn't be the case with Scala 3.3 (for a > certain > > > > period of time). > > > > > > > > Of course the counter argument to using Scala 3.3 is that it would > > force > > > > all potential Pekko users (and the transitive set of Scala 3 > libraries > > > for > > > > that Pekko user) to also use/support Scala 3.3. Unfortunately its not > > > > possible to get download stats from Sonatype for artifacts you don't > > > > maintain, but I wouldn't say its a controversial statement that the > > > amount > > > > of people that use Akka long with Scala 3 would be a tiny minority > > (this > > > is > > > > also regarding other factors, i.e. the typical demographic of Akka > > > users). > > > > Ontop of this we need to take into account the delay of current Akka > > > users > > > > migrating to Pekko, in other words by the time people migrate to > using > > > > Pekko the fact that its using Scala 3.3 LTS would likely be a non > > concern > > > > at that point in time. > > > > > > > > And finally another thing to note is that even in the worst case > > > scenario, > > > > nothing is stopping users from using Scala 2 artifacts from within > > Scala > > > 3 > > > > (this is perfectly supported and has been for a while). Afaik the > > current > > > > Scala 3 version of Akka/Pekko is not using any unique/bespoke > features > > of > > > > Scala 3, if true this would mean from a Scala 3 user perspective > there > > > > really isn't going to be > > > > a difference in using a Scala 2 artifact vs Scala 3 artifact. > > > > > > > > For these reasons my recommendation would be, assuming that the full > > > > release of Scala 3.3 LTS is ready by the time we decide to make a > > release > > > > that we should try and target that. For details on the current > release > > > > schedule for Scala 3.3 LTS you can read > > > > https://contributors.scala-lang.org/t/3-3-0-release-thread/6079/3. > > > > > > > > -- > > > > > > > > Matthew de Detrich > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > *m:* +491603708037 > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io
