<div dir="ltr"><div dir="ltr">On Sun, Mar 31, 2024 at 11:30 AM Volker Wysk <<a href="mailto:post@volker-wysk.de">post@volker-wysk.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So what happens when a new GHC version is released? It depends on the<br>
version of the base package, which it ships. When the base package doesn't<br>
get an API-breaking change, then all is well. <br></blockquote><div><br></div><div>There's an implicit contract that such major changes will be guarded behind an epoch version bump, so you'll see many packages depending on `base < 5`.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When it *does* have such a change, all the Hackage packages must be checked<br>
for compatibility with the new compiler version, and the upper bound of the<br>
base package version must be adjusted. That sounds like a lot of effort. It<br>
would be major happening in the Haskell community.<br></blockquote><div><br></div><div>See <a href="https://ghc.gitlab.haskell.org/head.hackage/">https://ghc.gitlab.haskell.org/head.hackage/</a> . In short, a large proportion of Hackage (I think corresponding to the most recent Stackage LTS?) is tested regularly, and needed changes to packages are made as overlays in head.hackage and submitted upstream before releases. </div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div></div>