GHC release timing and future build infrastructure
me at ara.io
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
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs