Since I can’t be bothered with setting up yet another “git-house” account - the suggestion by @santiweight:
Another point to make is that the naming scheme is here is imo quite poor. Intuitively, 9.0 would appear to be a long-term support release since it is [a] major version bump. […]
is quite reasonable:
- ghc-
v
.0
.n
(for largestn
) - the most recent maintenance-only version which provides relative stability; - ghc-
v
.k
.m
(fork > 0
) - for adding and testing language and other extensions; - ghc-HEAD - for those wanting to stay at the “leading/bleeding/cutting edge”.
However, as noted by @hasufell :
[…] that would boil down to maintaining a stable fork of GHC […] and observe its popularity.
…which raises some other questions:
- are there enough GHC developers available to support both codebases, at least for an initial trial with ghc-9.0?
- If successful, will enough GHC developers be willing to continue being maintainers?
If not, and in the absence of other options, then the choice is obvious, at least for non-breaking changes. As for those other changes, the simplest option is to slow down the release rate as suggested by @Bodigrim, until the breakage has been dealt with.