<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Glad I could provide some useful thoughts!</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">You are to some extent correct; an unwillingness to release before major</span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">(for some definition of "major") bugs are fixed will inevitably lead to<br>slips. However, I think a faster release cycle will make it easier to<br>accept releases with such bugs (at least in the case of non-regressions).</span></font></blockquote><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">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.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">I agree that Rust is a bit extreme. Even with ideal tooling I don't</span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">think that GHC could manage the cadence maintained by Rust, nor do I<br>think we should. The language is simply at a much different point in its<br>evolution. Their strong adherence to stability certainly also helps.</span></font></blockquote><br></div><div id="AppleMailSignature">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. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Indeed tools have improved remarkably in the Haskell community over the<br>past few years. However, I feel like a word like "trivial" may be a bit<br>strong here. Afterall, library authors still need to follow changes in<br>core libraries (e.g. template-haskell, ghc-prim, and ghc itself). This<br>does require effort, although perhaps on the part of a smaller number of<br>people.</span></font></blockquote><br></div><div id="AppleMailSignature">Trivial was perhaps somewhat overstating the current state of the ecosystem, yes. I nevertheless<span class="Apple-tab-span" style="white-space:pre"> </span> see `stack` as a huge boon for easing adoption of new compiler versions (and hence new language features/extensions).</div><br>_ara</div><div id="AppleMailSignature"><br></div><blockquote type="cite"><div><snip></div></blockquote><br></body></html>