Here we propose to formalize a rather long-standing pattern in GHC’s release history, specifying a “bimodal” release cycle and giving concrete support windows for these releases. We hope that the this will provide better guidance to commercial users seeking to migrate between GHC versions and make it easier to plan the GHC release process.
6 Likes
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.
2 Likes