<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Michael,<div class=""><br class=""></div><div class="">Thanks for bringing up these points. As you, and also Mathieu highlight, we need to think carefully about the exact process and the guarantees that releases come with. The overarching goal here is to get more predictable GHC releases, both in terms of when releases happen and how solid they are — and, we should add to that, as you rightly point out, what changes they bring. This is why I initiated this discussion, to ensure that we end up with something that helps everybody, GHC developers, package authors, and GHC users.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">23.10.2017, 19:55, Michael Snoyman <<a href="mailto:michael@snoyman.com" class="">michael@snoyman.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div><div class="">* 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></div></blockquote><div><br class=""></div><div>Yes, Ben raised this point earlier as well. If we do more releases, we need to adapt this policy such that we again end up with about 3 years support; e.g., for a release every 6 month, we would need to have a 6 versions support policy.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">* 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></div></blockquote><div><br class=""></div>Yes, and that is something that I really like to see changing. Given that you have the greatest insight into Stackage of all of us, I’d be really keen to hear your opinion on the reasons for that.</div><div><br class=""></div><div>I actually think that the three main factors are (1) the long time between GHC releases, (2) the number of problems with RCs and the first release, and (3) the lack of CI, in generally, and automated testing against packages, in particular.</div><div><br class=""></div><div>Re (1), this leads more fundamental and multiple changes in GHC; i.e., more breakage per package and release. This leads to dread on the package authors side.</div><div><br class=""></div><div>Re (2), for many package authors, the RCs are unusable, due to problems with the RCs and because packages they depend on don’t build. Unfortunately, even the first release often has similar problems.</div><div><br class=""></div><div>Re (3), feedback about what things a GHC release breaks gets to package authors way too late. This is compounded by the currently very long time between releases.</div><div><br class=""></div><div>What do you think?</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Personally, I'd be much more interested in seeing:</div><div class=""><br class=""></div><div class="">* 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 class="">* Perhaps some plans allowing for introducing new functionality in point releases without breaking backwards compatibility.</div><div class=""><br class=""></div><div class="">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 class=""></div></div></div></blockquote><div><br class=""></div><div>You write that you ”fear GHC releases”; so, let’s work towards changing the GHC release process such that you don’t fear them anymore.</div><div><br class=""></div><div>I guess, we all agree that we want more automated testing to avoid a whole range of breakage. This includes breaking changes in point releases, as you write, and also having initial release candidates that are of such high quality that package authors will test against them without dread. In particular, as Mathieu has mentioned, we have been working on a scheme to use Stackage for regression testing of GHC during development. (It’s one thing for packages to break, because of a genuine and planned change of the language or libraries, but any accidental breakage is ultimately avoidable.) However, for the moment, we first need to get the new CI story (which we discussed in a separate thread) set up. This is something, we all want and we will push it forward.</div><div><br class=""></div><div>If we can take the dread out of GHC releases, I think, more frequent release will help. Here is why. There will be fewer significant changes per release. Hence, fewer packages break and fewer broken package dependencies will have authors wait for fixes in dependencies before they can fix their packages. This coupled with having release candidates earlier in the process, makes me hopeful that we can have a stable package ecosystem on top of a new compiler release shortly after its release. (Once we regression test against Stackage, maybe even at the same time as the GHC release.)</div><div><br class=""></div><div>Cheers,</div><div>Manuel</div><div><br class=""></div><div>PS: BTW, somewhat related to this, there is currently a discussion on the GHC Steering Committee about regulating the stability of LANGUAGE extensions. I think, this has a clear relation to our discussion here: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/85" class="">https://github.com/ghc-proposals/ghc-proposals/pull/85</a> (please do voice your opinion on this proposal thread)</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 23, 2017 at 8:49 AM, Manuel M T Chakravarty <span dir="ltr" class=""><<a href="mailto:manuel.chakravarty@tweag.io" target="_blank" class="">manuel.chakravarty@tweag.io</a>></span> wrote:<br class=""><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" class="">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 class=""><br class=""></div><div class=""> 6.4 release planned for Feb</div> - Branch in Nov<br class=""><br class=""> 6.6 release ought to then be in Aug<br class=""> - Branch in May<br class=""><br class=""> Pre-release schedule<br class=""> - On cutting the branch, alpha release<br class=""> - Then, a beta every two weeks until 4 weeks before the targeted release date<br class=""> - RC1 four weeks before the targeted release date<br class=""> - RC2 two weeks before the targeted release date<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Ben, this also requires us to settle </div><div class=""><br class=""></div><div class=""> <a href="https://github.com/snowleopard/hadrian/issues/440" target="_blank" class="">https://github.com/<wbr class="">snowleopard/hadrian/issues/440</a></div><div class=""><br class=""></div><div class="">soon.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">What do you all think?</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Manuel</div><div class=""><br class=""></div></div><br class="">______________________________<wbr class="">_________________<br class="">
Ghc-devops-group mailing list<br class="">
<a href="mailto:Ghc-devops-group@haskell.org" class="">Ghc-devops-group@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-<wbr class="">bin/mailman/listinfo/ghc-<wbr class="">devops-group</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>