<div dir="ltr"><div>I'd like to add a third option to Andreas' list.</div><div><br></div><div>It seems the current policy is both too lax and too strict: Minor versions are never incorporated, but when they are, it is despite the fact they are known to create breakage. This is what I've gathered from Ben's comment that head.hackage caught the 9.8.3 breakage.</div><div><br></div><div>So the third option:<br></div><div><br></div><div>## Always bump minor versions, unless they are known to cause breakage.</div><div><br></div><div>(1) "Known to cause breakage" is subject to further specification, but at the very least, head.hackage can already be used for this purpose.<br></div><div><br></div><div>Tangentially, regardless of hard-and-fast rules, exceptions should be allowed if justified. This is also subject to further specification, but again at the very least, justification should be a mix of release manager's discretion, user needs, and library maintainer wishes. This might be stating the obvious, but it's only obvious if it's actually stated.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Nov 2024 at 14:51, Andreas Klebinger via ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>> Breaking changes caused by new exports could be mitigated
with a library package or a GHC plugin with such auto refactoring
functionality :<br>
<br>
All of this is true. But from my side the worry here is less the
effort required to fix such issues. <br>
Rather it's that users need to take any action at all when <br>
upgrading from ghc-9.X.Y to ghc-9.X.Y+1 in order for their
projects to continue to compile.<br>
<br>
Our goals here are:<br>
* Ensure bug fix releases of libraries are shipped with GHC
without requiring maintainer attention.<br>
* Try to keep breakage for users minimal.<br>
<br>
In concept the idea of only bumping sumperminor versions makes
sense, as those typically don't contain any breaking changes.<br>
But after looking through some of the changelogs of boot libraries
it seems like *many* bug fixes are currently released as minor<br>
releases. As a consequence I don't see applying this policy only
to superminor versions as productive unless the release practices<br>
of boot libraries change significantly which seems unlikely.</p>
<p>Similarly in theory we can disregard concerns about breakage with
a reference to best practices or paint users as responsible for
open<br>
imports. But that won't change the fact that it's common practice
to use open imports and as a result there will be breakage from
such<br>
changes.<br>
</p>
<p>So this leaves us with:<br>
<br>
## Always bump minor versions [unless there are objections].</p>
<p>This ensures bug fixes make it into releases reliably with little
maintainer burden, but will result in breakage for some projects<br>
when upgrading from ghc-X.Y.Z to ghc-X.Y.Z+1.<br>
<br>
Breakage from such issues tends to be immediately observed as tied
to a ghc upgrade, and as such we tend to more reliably hear of it.<br>
</p>
<p>## Never bump minor versions [unless explicitly requested by
maintainers of the library, or deemed necessary by ghc
maintainers].<br>
<br>
This reduces breakage from added imports, but means ghc might ship
at times with libraries which contain bugs for which a fix already
existed. It is hard to accurately judge the cost/benefit of this
approach. As such bugs typically are discovered once applications
are deployed and as ghc devs we might never hear of issues caused
this way.<br>
<br>
Some projects are also locked into boot library versions, and
might want to use newer versions for non-bugfix reasons.<br>
<br>
-----------------<br>
<br>
Personally I think we should bump minor versions by default
despite it occasionally causing breakage. However I think we
should also be willing to avoid a bump if it causes a large amount
of known breakage while not providing any bug fixes.<br>
<br>
For example we should probably not upgrade point releases from
text-2.1.1 to text-2.1.2 as the addition of `show` causes breakage
and there seem to be no bug fixes in the release, unless the
library authors request us to do so.<br>
<br>
<br>
</p>
<p><br>
<br>
<br>
<br>
</p>
<div>Am 28/11/2024 um 08:44 schrieb Imants
Cekusins:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Wed, 27 Nov 2024 at 11:58, Tom Ellis <<a href="mailto:tom-lists-haskell-cafe-2023@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2023@jaguarpaw.co.uk</a>>
wrote:</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">Thanks
Adam,<br>
<br>
I'm not too familiar with the GHC-side requirements here,
but I wonder<br>
if we can approach this issue from a different direction: is
there<br>
something we can do to help boot libraries avoid breaking
changes?<br>
<br>
Tom<br>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Breaking changes caused by new exports could be mitigated
with a library package or a GHC plugin with such auto
refactoring functionality :</div>
<br>
* Uniquely qualify (i.e., leave no different modules similarly
qualified in the same module) each imported module and each
imported symbol. <br>
<br>
This refactoring should be possible in code which already
compiles.<br>
It would not require syntax / grammar changes.<br>
<br>
Something similar to smuggler2 package.<br>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
ghc-devs mailing list
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>