You are to some extent correct; an unwillingness to release before major

(for some definition of "major") bugs are fixed will inevitably lead to
slips. However, I think a faster release cycle will make it easier to
accept releases with such bugs (at least in the case of non-regressions).

I definitely agree that a shortened release cadence would help with the reduction of release blockers by making som things more acceptable. I think this would be one of the major benefits of shortening the release cycle.

I agree that Rust is a bit extreme. Even with ideal tooling I don't

think that GHC could manage the cadence maintained by Rust, nor do I
think we should. The language is simply at a much different point in its
evolution. Their strong adherence to stability certainly also helps.

I'm definitely with you here. I think that a 3-month release cycle is the shortest that would work for GHC, but that would require a perfect set of tooling which we don't quite have yet. Your originally proposed six months sounds great to me, and I don't see an reason why it couldn't be altered further down the line if it wasn't quite working.

Indeed tools have improved remarkably in the Haskell community over the
past few years. However, I feel like a word like "trivial" may be a bit
strong here. Afterall, library authors still need to follow changes in
core libraries (e.g. template-haskell, ghc-prim, and ghc itself). This
does require effort, although perhaps on the part of a smaller number of
people.

Trivial was perhaps somewhat overstating the current state of the ecosystem, yes. I nevertheless see `stack` as a huge boon for easing adoption of new compiler versions (and hence new language features/extensions).

_ara