Bug#1125161: Re-bootstrapping sbt and modern Scala; the Scala 3 path is now open

[Juan M. Méndez Rey]

El jueves, 11 de junio de 2026 a las 10:12, Emmanuel Bourg <ebourg at apache.org> 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