On Thursday, 11 June 2026 10:12:53 British Summer Time Juan M. Méndez Rey wrote: > 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.
Except that Scala 3 is just in a transition (with 3.8 and the new LTS now in RC1 3.9 which abandon the 2.13 library and move to a new library rebuilt with Scala 3. Sorry to throw a spanner in the works. BTW, I am all for getting Scala as a proper debian package. Although actually all that are really needed is sbt and scala-cli and these two will bring in the relevant libraries for you. sbt is about to go to version 2.0 (which is being built on Scala 3) and scala-cli now follows the Scala 3 releases. I have used the DEB files for these two that virtuslab release. > > 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
