<div dir="ltr"><div>I'm likely going to be a contrary opinion here: I'd prefer _less_ frequent GHC releases, not more frequent. Or at the very least: if we're talking about major releases with intentional breakage, I see multiple problems:</div><div><br></div><div>* Many libraries are subscribing to a "3 versions" support policy. Having a breaking release every 6 months means that libraries will be phasing out support for a GHC release after only 1.5 years.</div><div>* From a Stackage perspective, I see how long it takes for the ecosystem to catch up to a new GHC release. Depending on what it means for the ecosystem to have caught up, I'd put that number anywhere from 2-4 months.</div><div><br></div><div>Personally, I'd be much more interested in seeing:</div><div><br></div><div>* More frequent point releases, with more guarantees of backwards compatibility between releases. We've had situations in the past where point releases have broken a significant number of packages, and it would be great if we could work towards avoiding that with automated testing.</div><div>* Perhaps some plans allowing for introducing new functionality in point releases without breaking backwards compatibility.</div><div><br></div><div>From the standpoints of a package author, a tooling maintainer, and someone helping companies with commercial rollouts of Haskell code, I've grown to fear GHC releases. I'd rather we fix those problems before increasing frequency.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 23, 2017 at 8:49 AM, Manuel M T Chakravarty <span dir="ltr"><<a href="mailto:manuel.chakravarty@tweag.io" target="_blank">manuel.chakravarty@tweag.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">One of the stated goals of our effort is to move to calendar-based 6-monthly releases of GHC. To this end, I had a conversation with Ben a while ago, where discussed the following schedule for v6.4 & v6.6:<div><br></div><div>  6.4 release planned for Feb</div>  - Branch in Nov<br><br>  6.6 release ought to then be in Aug<br>  - Branch in May<br><br>  Pre-release schedule<br>  - On cutting the branch, alpha release<br>  - Then, a beta every two weeks until 4 weeks before the targeted release date<br>  - RC1 four weeks before the targeted release date<br>  - RC2 two weeks before the targeted release date<div><br></div><div>For this to be realistic, we do need to have the automatic release artefact building in place by the time of cutting the v6.4 branch. This doesn’t leave us much time to get this up and running.</div><div><br></div><div>Ben, this also requires us to settle </div><div><br></div><div>  <a href="https://github.com/snowleopard/hadrian/issues/440" target="_blank">https://github.com/<wbr>snowleopard/hadrian/issues/440</a></div><div><br></div><div>soon.</div><div><br></div><div>We need to discuss a policy of what can go into the release branch after it has been cut. IMHO, it cannot be major features, but only small changes and fixes until RC1. Then, only fixes.</div><div><br></div><div>What do you all think?</div><div><br></div><div>Cheers,</div><div>Manuel</div><div><br></div></div><br>______________________________<wbr>_________________<br>
Ghc-devops-group mailing list<br>
<a href="mailto:Ghc-devops-group@haskell.org">Ghc-devops-group@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>devops-group</a><br>
<br></blockquote></div><br></div>