Proposed by Lars Hupel.
Scala 2.10 used to (and still has, to some extent), huge gravitas in the Scala ecosystem. To large parts, this was due to Spark and sbt supporting only 2.10. Spark has migrated to 2.11, and sbt 1.0.x is already there (the RCs are binary compatible).
Most Scala libraries (as far as I can tell), cross-build against at least 2.10, 2.11, and 2.12. Some even added support for 2.13, which means four major Scala versions.
One one hand, this is a significant improvement over the state of the art before 2.10: It was unthinkable to support so many versions simultaneously with as little changed code.
On the other hand, it is also a maintenance burden. Good cross-compatibility also means that progress is hindered. Libraries are unable to exploit newer features from, say, 2.11.x (partial unification aka SI-2712 comes to mind).
Dropping Scala 2.10 support and moving the sbt ecosystem forward to sbt 1.0.x are intertwined issues with combined benefits. It means version switches in build files (e.g. for Scala modules like scala-xml) or compatibility libraries (e.g. macro-compat) can go away. In almost all cases I’ve seen, this was used to distinguish between 2.10 and 2.11+. It also ensures we're not eternally stuck on a Scala version released many years ago.
The Scala Center should devote time to
- analyse the usage of sbt plugins "in the wild",
- prioritize plugins according to usage,
- send pull requests updating to sbt 1.0.x, and
- if necessary, push releases, in case the maintainer(s) are unresponsive
Flexible, but the sooner, the better. Many popular plugins are already taken care of, but there's a very long tail of sbt plugins. Every little helps.
Update: scalacenter/advisoryboard#28