When is there a sbt version for 2.13?

I would like to develop a sbt plugin that has dependencies that are only available for Scala 2.13 .

I found on https://github.com/sbt/sbt/issues/5032 this list:

  • SBT 0.x runs only on Scala 2.10.x
  • SBT 1.x runs only on Scala 2.12.x
  • SBT 2.x will run only on Scala 2.13.x or 3.0.x
  • SBT 3.x will run only on Scala 3.0.x or Scala 3.1.x

Where the last two lines was a guess by the author mr-git .

However I did not find any other glue if there is actually a version for Scala 2.13 .

I also asked here: https://stackoverflow.com/questions/59377410/when-is-there-a-sbt-version-for-2-13

Binary non-compatible sbt 2.x would require all sbt plugins to be published again, and I’m reluctant to burn the forest down. (sbt 0.13 kept one of the longest record of bincompat) So I don’t have an immediate plan to bump to Scala 2.13 for the sake of Scala 2.13.

Something that would trigger sbt 2.x I think would be one or combination of the following:

  • sbt 2.x that allows us to add new feature that’s not bincompat
  • Scala 3.x requires new tooling
  • maintaining Scala 2.12 libraries starts to become a burden for the community (This is what happened to sbt 0.13)
  • maintaining Scala 2.12 itself starts to become a burden for Lightbend Scala team
  • sbt migrates to Scala 3.x to make sure macros still work

I’d be happy to hear others’ thoughts on this.

Here’s my proposal from last year: Sbt plugins and future binary-incompatible Scala versions

Also, in light of https://github.com/scala/scala-lang/pull/1098, moving to 2.13 would be a great way to make sbt future-proof for a long period of time.

Curious, what are those dependencies?

@nafg It is a dependency to a library of our own. So the workaround was to but the required classes to a separate module and cross-compile it.

Not so nice (lots of deprecation warnings), but it works.

I would love to see sbt on 2.13! Given the announcement for Scala 3 (https://scala-lang.org/2019/12/18/road-to-scala-3.html), I suspect the 2.13 Scala library will be long lived and a more stable foundation for the sbt plugin ecosystem compared to 2.12. I am also curious to know how much the improved 2.13 collection performance can help improve sbt performance.

It would be nice to avoid repeating the situation with 0.13 where it was pretty painful for 1-2 years to build sbt plugins against 2.10. There’s reason to believe it will be easier to bootstrap a 2.x plugin ecosystem compared to 1.x because the community already has some experience cross-building sbt plugins against 0.13.x and 1.x. If the 2.x API has limited breaking changes, then the upgrade should be smooth for most existing plugins.

2 Likes