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.
Just to add some information to help develop this proposal a bit:
To be able to move forward on this proposal and hopefully get it accepted at the next AB meeting, we'll need to better work out the cost & timescales section. We've lost 2 advisory board members, which means the SC has to downsize. That said, we have to be a bit stricter about how much the SC should invest in new initiatives given that we already have quite a few open-ended initiatives in our queue; adding more without knowing how much time/effort everybody thinks we should invest could make it difficult for us to meet expectations on this and across all other projects.