<html><head>

<style id="css_styles" type="text/css"><!--blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
table { border-collapse: collapse; }
li[style='text-align: center;'], li[style='text-align: center; '], li[style='text-align: right;'], li[style='text-align: right; '] {  list-style-position: inside;}
body { font-family: 'Segoe UI'; font-size: 12pt; }
.quote { margin-left: 1em; margin-right: 1em; border-left: 5px #ebebeb solid; padding-left: 0.3em; }
a.em-mention[href] { text-decoration: none; color: inherit; border-radius: 3px; padding-left: 2px; padding-right: 2px; background-color: #e2e2e2; }
--></style></head><body class="plain"><div>Hi,</div><div><br /></div><div>Do we have concrete evidence that minor bumps in a boot library have caused breakage in the past? (That would of course be a bug in the boot library according to the PVP.)</div><div><br /></div><div>I would think that such breakage is even <i>less </i>of an issue for a new GHC minor release (say GHC 9.8.4).</div><div><span>The hackage ecosystem is likely prepared to compile with the GHC 9.8 series at this point, so it should be possible to detect such breakages by compiling stackage/hackage and running testsuites.</span></div><div><span>That is, I would think it is harder to anticipate unforeseen boot library breakage for a new major release of GHC than it is to anticipate breakage for a minor GHC release.</span></div><div><span><br /></span></div><div><span>Besides, the only reliable way to prevent such breakage is not to bump any boot library *at all*.<br />If a boot library breaks on a minor bump, it is just as likely that it breaks on a super-minor bump.</span></div>
<div><br /></div><div>So bumping minor versions of boot library sounds reasonable to me, barring concrete evidence that minor bumps have caused problems in the past (which again </div><div>means there was a bug in a boot library).</div><div><br /></div><div>Sebastian</div>
<div><br /></div>
<div>
<div>------ Originalnachricht ------</div>
<div>Von "Tom Ellis" <tom-lists-haskell-cafe-2023@jaguarpaw.co.uk></div>
<div>An ghc-devs@haskell.org</div>
<div>Datum 27.11.2024 10:57:57</div>
<div>Betreff Re: Feedback on potential change in boot library</div></div><div><br /></div>
<div id="xcfd51818680b4b0"><blockquote type="cite" class="cite2">

<div class="plain_line">Thanks Adam,</div>
<div class="plain_line"> </div>
<div class="plain_line">I'm not too familiar with the GHC-side requirements here, but I wonder</div>
<div class="plain_line">if we can approach this issue from a different direction: is there</div>
<div class="plain_line">something we can do to help boot libraries avoid breaking changes?</div>
<div class="plain_line"> </div>
<div class="plain_line">Tom</div>
<div class="plain_line"> </div>
<div class="plain_line"> </div>
<div class="plain_line">On Wed, Nov 27, 2024 at 08:02:10AM +0000, Adam Gundry wrote:</div>
<blockquote type="cite" class="cite">
<div class="plain_line"> It's not obvious to me that this is a good idea. Users already complain that</div>
<div class="plain_line"> "upgrading GHC broke my code", when in practice this frequently means "when</div>
<div class="plain_line"> upgrading GHC I used new boot library versions with incompatible APIs that</div>
<div class="plain_line"> broke my code". So having a policy of introducing more frequent API changes</div>
<div class="plain_line"> (and making it harder to switch between GHC releases in a single release</div>
<div class="plain_line"> series) needs clear justification IMHO.</div>
<div class="plain_line"> </div>
<div class="plain_line"> (Of course in the long term we should make it easier for users to pin boot</div>
<div class="plain_line"> library APIs while upgrading GHC independently, but we're not there yet.)</div>
<div class="plain_line"> </div>
<div class="plain_line"> I think that by default, it makes sense for a new minor GHC release to keep</div>
<div class="plain_line"> the same API versions of boot libraries, but bump to the latest super-minor</div>
<div class="plain_line"> component (i.e. for an A.B.C.D version, keep A.B.C the same but bump D). If</div>
<div class="plain_line"> a boot library fixes a bug that is critical enough to require bumping the</div>
<div class="plain_line"> version distributed with GHC, ideally there would be an API-compatible</div>
<div class="plain_line"> release of the boot library. Of course that might not always be feasible,</div>
<div class="plain_line"> and it is ultimately a judgement call for the GHC maintainers as to which</div>
<div class="plain_line"> boot library versions are best to ship.</div>
<div class="plain_line"> </div>
<div class="plain_line"> On 26/11/2024 22:27, Hécate via ghc-devs wrote:</div>
<div class="plain_line"> >  From the cabal perspective this great news, as this will allow the</div>
<div class="plain_line"> > feedback cycle between our two projects to be shorter. Glad to see the</div>
<div class="plain_line"> > GHC team is considering this!</div>
<div class="plain_line"> ></div>
<div class="plain_line"> > Cheers,</div>
<div class="plain_line"> > Hécate</div>
<div class="plain_line"> ></div>
<div class="plain_line"> > Le 26/11/2024 à 21:14, Ben Gamari a écrit :</div>
<div class="plain_line"> > > tl;dr. We propose that GHC more aggressively bump its boot library</div>
<div class="plain_line"> > >         dependencies.</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > > Hello all,</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > > Historically, GHC minor releases have been quite conservative in bumping</div>
<div class="plain_line"> > > boot library versions, generally defaulting to retaining the versions</div>
<div class="plain_line"> > > used in the GHC-x.y.1 release unless</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > >   * a request is made by a boot library maintainer, or</div>
<div class="plain_line"> > >   * we discover an issue which warrants a bump</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > > The motivation for this policy is both to</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > >   * minimize the potential for regressions in correctness and</div>
<div class="plain_line"> > >     performance, and</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > >   * reduce the potential for end-user breakage due to interface changes</div>
<div class="plain_line"> > >     as even minor releases can result in considerable impact (e.g.</div>
<div class="plain_line"> > >     #25411, #22633)</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > > While this policy has served us well, its conservative nature demands</div>
<div class="plain_line"> > > the vigilence of both GHC and upstream maintainers to ensure that bumps</div>
<div class="plain_line"> > > that are truly necessary do not fall through the cracks.</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > > As the flaws of this process have been more apparent recently (e.g.</div>
<div class="plain_line"> > > #24597), we have done a bit of reflection on how we might improve the</div>
<div class="plain_line"> > > status quo. Concretely, I would like feedback on the adopting the</div>
<div class="plain_line"> > > following policy going forward:</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > > > Unless guidance is provided otherwise by a library maintainer, a GHC</div>
<div class="plain_line"> > > > x.y.z release will attempt to ship the newest minor version of each</div>
<div class="plain_line"> > > > boot libray in the same major series shipped with GHC x.y.1.</div>
<div class="plain_line"> > > I believe this policy would leave less room for human error and open</div>
<div class="plain_line"> > > opportunities for automated checking. On the other hand, the more</div>
<div class="plain_line"> > > aggressive bumping of submodules may mean that users are hit with more</div>
<div class="plain_line"> > > (usually minor) compatibility issues when moving between minor GHC</div>
<div class="plain_line"> > > releases.</div>
<div class="plain_line"> > ></div>
<div class="plain_line"> > > How do others feel about this? We are particularly interested to hear</div>
<div class="plain_line"> > > from boot library maintainers but feedback from packagers and users is</div>
<div class="plain_line"> > > also very much welcome.</div>
</blockquote>
<div class="plain_line">_______________________________________________</div>
<div class="plain_line">ghc-devs mailing list</div>
<div class="plain_line">ghc-devs@haskell.org</div>
<div class="plain_line">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</div>
</blockquote></div>
</body></html>