GHC release timing and future build infrastructure

Ara Adkins me at
Thu Aug 3 06:41:59 UTC 2017

Glad I could provide some useful thoughts!

> 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).


> <snip>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list