A tick-tock release cycle for GHC

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 largest n) - the most recent maintenance-only version which provides relative stability;
  • ghc-v.k.m (for k > 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