<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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 class="moz-cite-prefix">Am 28/11/2024 um 08:44 schrieb Imants
Cekusins:<br>
</div>
<blockquote type="cite"
cite="mid:CAP1qinaSWeXx-Ttnzn7O3ieNHcUTfZ+WUUZa-EAL7e+uMcpyoQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">tom-lists-haskell-cafe-2023@jaguarpaw.co.uk</a>>
wrote:</div>
<div class="gmail_quote gmail_quote_container">
<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 class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</body>
</html>