2.11.0 was released a little over 14 months ago (https://github.com/scala/scala/releases/tag/v2.11.0). 2.12.0 is planned for Q1 2016. In principle, the core of 2.12.0 will very likely compile on 2.11.x. You can then build the 2.12 modules with 2.12.0. In practice, we don't test this (we could/should), as we build 2.12.0 with milestones/RCs of 2.12.

Right, so that's probably the policy/practice I'm asking to change here. If 2.11->2.12 was an officially tested and supportable thing, we could relax out build-dependency requirements and not feel like we're forced to rebootstrap on every major upstream release.

And, if it's just the core (which makes sense) that carries that guarantee (or, really, even just a subset of the core), that just means changing the bootstrap method to be multiple stages to allow one to get from A to D through B and C without reinventing that wheel themselves.

Indeed, one can't build the majority of GCC without a recent GCC (and, often, without the very same version you're building), but the upstream build process takes this into account and lets you just pass CC=foo and it sorts out a bootstrap compiler to build the real compiler to build the rest of the suite, so this isn't something we need to figure out over and over again.

What I'm wondering is whether packaging Scala is actually the thing that should get priority.
Wouldn't it be more helpful to ship a current version of SBT first? People can then easily pick the Scala version they need, instead of having some random global version (which is just not even remotely how Scala development works).

Don't take me wrong, I'm a fan of package managers, but I think the quest to manually re-package every Java/Scala/... compiler/framework/library under the sun is doomed to fail. Is there any actual package in Debian that would depend on Scala?

Good point Simon.

To clarify my message, I fully expect it to be possible to bootstrap 2.11.7 from 2.10.x, but we don't guarantee this since we don't have the resources right now to test this workflow. If someone were to try this and came to rely one it, we would be happy help make sure it doesn't regress. We're not super policy driven or constrained – a CI job (we can take care of that) and someone to ping when it breaks would suffice.

Note that it's settled that Scala's old ant-based build will be removed very soon from the 2.12.x branch, in favor of the new sbt build.

There was some discussion recently about the implications of this for Debian et al at https://github.com/scala/scala/pull/5311 ; that discussion can continue here.