Feedback on potential change in boot library

[Bryan Richter]

I'd like to add a third option to Andreas' list.

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.

So the third option:

## Always bump minor versions, unless they are known to cause breakage.

(1) "Known to cause breakage" is subject to further specification, but at
the very least, head.hackage can already be used for this purpose.

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.

On Thu, 28 Nov 2024 at 14:51, Andreas Klebinger via ghc-devs <
ghc-devs at haskell.org> wrote:

> > 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 listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> 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/20241217/4c30ec16/attachment.html>