El jueves, 11 de junio de 2026 a las 10:12, Emmanuel Bourg <[email protected]> escribió:
> Hi Juan, > > Thank you very much for working on Scala, I gave up years ago and I'm > glad someone is picking up the ball. Thanks Emmanuel, glad to be able to hear your opinions with this, that means a lot, and what I found probably is related with your experience. > I see there is a choice about preserving the old version (2.11) or not. > If you are confident packaging a new version of Scala is achievable, > then I'd vote for retiring the old version. I can't definitely say, but I concur that most of the biggest projects migrated long ago to Scala 2.12, Scala 2.13. e.g.: Spark, Almond, not sure how Metals and Joern are in regard of this. > There is also a decision to make between upgrading the existing scala > package, or switching to versioned scala-x.y packages (the existing > scala package could then depend on the latest version, similarly to the > default-jre package). The key factor here is backward compatibility, how > stable is Scala nowadays? Do libraries still have to be rebuilt for new > Scala versions? If so a versioned package might be more appropriate. There are also packages depending on Scala 2.11: plm, pilon, latexdraw, htsjdk, unicycler: they would need to be ported to 2.13 o r think about retiring them if we would remove 2.11. Regarding versioned scala-x.y vs upgrading scala: versioned, for the compatibility reason you raise. Scala is binary compatible within a minor (any 2.13.x library works on any 2.13.x) but not across minors, so every library is cross-compiled per series: e.g.: upstream encodes it in the name (foo_2.12, foo_2.13, foo_3). We can mirror default-jdk: real scala-2.12/scala-2.13/scala3 plus a thin scala metapackage. scala-2.12 already exists in that shape; Scala 3 is stable across 3.x and reuses the 2.13 library, so it slots in. > Did you consider bootstrapping Scala 3 directly instead of starting from > 2.12? Wouldn't that be easier? That was my initial question too. Why not bootstrap 3 directly: But I found this: It doesn't avoid the work: sbt (which 2.13 and 3 both build with) is itself built with Scala 2.12, Scala 3's stdlib is the 2.13 library, and Dotty self-bootstraps from a prior Scala 3 too. Going straight to 3 would mean front-loading more prebuilt seeds (a 3 compiler + sbt + a 2.13 STARR), meaning a bigger exemption to defend in NEW, not a smaller one. The 2.12 seed is the smallest binary that unlocks the whole chain and drops out after self-host. I also factored in all the apps like Spark that still is getting users everywhere and that is in 2.12/2.13. My proposed plan then is: coexistence scala-asm (MR !3) + versioned toolchain now, retire 2.11 once its rdeps migrate. Although I see it is open to the team's preference on regard of the metapackage naming. Please, Let me know what you think, Juan
