As a data point: Scala versions currently come in 6 flavors:
Little to no maintenance (<2.12, so 3 effectively 3 major language revisions back). No new features ever. It is a miracle if modern code compiles on this version.
Bug fixes only (2.12, 2 major language revisions back). This series largely supports slow-moving enterprises stuck on ancient versions of web frameworks and Spark. As far as I know, the only major changes in recent memory are for JDK compat and bumping the XML library version.
Lingua franca (2.13, 1 major language revision back). This the core dialect for people who need to support 2.12-3.x. The bulk of the compatibility fixes and tooling support goes here. There’s MiMa (Migration Manager) which detects binary compat problems between releases of a given project and TASTy-MiMa that detects incompatilities in the typed AST interchange format TASTy that allows 2.13 compilation to depend on 3.x artifacts and vice versa.
LTS - Last major language revision (3.3.x). Forward ports from 2.13, bug fixes, compat fixes, but no major revisions. Strong binary compat, and I think the surface language is largely frozen until the next LTS.
Next - Binary compatible, but aggressively not source compatible. Lots of changes in the surface language, compiler internals, etc. Many experimental features land here behind flags to collect usage reports and work through problems.
Nightly - Utterly experimental. No idea what goes on here because I’m not paid to work on the compiler
EDIT: To put more of a point to it, do we have analogous facilities for some of these forward/backward compat axes? The GHC API? Core?
There was a follow up meeting with the stability group (thanks to @telser) that yielded further clarity. I believe we will be updated by GHC HQ soon enough on the status.
My opinion is that this is a great experiment and it is fairly low risk. If it doesn’t work well, we don’t have to continue it.
My hope is that it may increase excitement about releases, because expectations are much more clear.
So far, GHC releases have been all over and it was up to us to figure out what works well, push for new point releases and so on. This won’t be neceasary anymore.
I think LTS releases may not solve the burnout issue for, say, core library maintainers (or other popular packages). It also doesn’t reduce my distributor workload at all. But it’s likely very useful for industrial users, application developers and hobbyists. It may also enable us to schedule breaking changes better (more on that later, probably).
To really reduce burnout of hackage maintainers, I believe we need:
decoupled base
better tools to execute automatic code migrations
core library maintainers doing less breaking changes OR maintaining more than one branch (this will likely increase your workload as text/bytestring maintainer)
a better story for upper bounds bumping
Conceptually, a user should be able to upgrade GHC without updating any libraries. Then they only have to deal with breaking changes to the surface language (which are probably scarce).
However, this may not solve the hackage maintainer burnout issue either… it just allows us to switch to new GHC versions faster with less work. The burnout issue is the sum of all the churn, including libraries. But if you can upgrade GHC without upgrading libraries, then there is less incentive in the ecosystem to support, say, a new text major version early.
It’s hard to foresee all the effects this might have, but I think it would generally be a much better situation.
I should of course point out that minutes don’t always capture each tiny detail. But I do think that this captures the results of the two meetings fairly well.
Thanks to everyone involved for being so constructive!
I’m not a major library maintainer, so I can’t speak for them, but I really like the conclusion at the end: Try to put breaking changes into non-LTS releases so that people have time and warning to update things before the next LTS release.
It seems like the GHC team will get the feedback they need, and library developers will be able to test things without feeling overstretched or guilty for dropping support from a non-LTS GHC release. It’s a good way of communicating intent between GHC and industry users.
GHC Devs will try to avoid big changes for LTS releases. People worry about the length of the support window, so the GHC devs will try to aim for the longer rather than the shorter. And keeping track of migration knowledge between releases.
Tom wanted to acknowledge the work of the SWG in reducing the amount of churn in the ecosystem.
