Feedback on potential change in boot library

[Andreas Klebinger]

 > Breaking changes caused by new exports could be mitigated with a
library package or a GHC plugin with such auto refactoring functionality :

All of this is true. But from my side the worry here is less the effort
required to fix such issues.
Rather it's that users need to take any action at all when
upgrading from ghc-9.X.Y to ghc-9.X.Y+1 in order for their projects to
continue to compile.

Our goals here are:
* Ensure bug fix releases of libraries are shipped with GHC without
requiring maintainer attention.
* Try to keep breakage for users minimal.

In concept the idea of only bumping sumperminor versions makes sense, as
those typically don't contain any breaking changes.
But after looking through some of the changelogs of boot libraries it
seems like *many* bug fixes are currently released as minor
releases. As a consequence I don't see applying this policy only to
superminor versions as productive unless the release practices
of boot libraries change significantly which seems unlikely.

Similarly in theory we can disregard concerns about breakage with a
reference to best practices or paint users as responsible for open
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
changes.

So this leaves us with:

## Always bump minor versions [unless there are objections].

This ensures bug fixes make it into releases reliably with little
maintainer burden, but will result in breakage for some projects
when upgrading from ghc-X.Y.Z to ghc-X.Y.Z+1.

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.

## Never bump minor versions [unless explicitly requested by maintainers
of the library, or deemed necessary by ghc maintainers].

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.

Some projects are also locked into boot library versions, and might want
to use newer versions for non-bugfix reasons.

-----------------

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.

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.






Am 28/11/2024 um 08:44 schrieb Imants Cekusins:
> On Wed, 27 Nov 2024 at 11:58, Tom Ellis
> <tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote:
>
>     Thanks Adam,
>
>     I'm not too familiar with the GHC-side requirements here, but I wonder
>     if we can approach this issue from a different direction: is there
>     something we can do to help boot libraries avoid breaking changes?
>
>     Tom
>
>
>
> Breaking changes caused by new exports could be mitigated with a
> library package or a GHC plugin with such auto refactoring functionality :
>
> * Uniquely qualify (i.e., leave no different modules similarly
> qualified in the same module) each imported module and each imported
> symbol.
>
> This refactoring should be possible in code which already compiles.
> It would not require syntax / grammar changes.
>
> Something similar to smuggler2 package.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241128/6195815f/attachment.html>