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). _ara > <snip>
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
