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
