[GHC-Releases] Feedback on potential change in boot library

Wed Nov 27 10:15:22 UTC 2024

Hi,

Do we have concrete evidence that minor bumps in a boot library have 
caused breakage in the past? (That would of course be a bug in the boot 
library according to the PVP.)

I would think that such breakage is even less of an issue for a new GHC 
minor release (say GHC 9.8.4).
The hackage ecosystem is likely prepared to compile with the GHC 9.8 
series at this point, so it should be possible to detect such breakages 
by compiling stackage/hackage and running testsuites.
That is, I would think it is harder to anticipate unforeseen boot 
library breakage for a new major release of GHC than it is to anticipate 
breakage for a minor GHC release.

Besides, the only reliable way to prevent such breakage is not to bump 
any boot library *at all*.
If a boot library breaks on a minor bump, it is just as likely that it 
breaks on a super-minor bump.

So bumping minor versions of boot library sounds reasonable to me, 
barring concrete evidence that minor bumps have caused problems in the 
past (which again
means there was a bug in a boot library).

Sebastian

------ Originalnachricht ------
Von "Tom Ellis" <tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk>
An ghc-devs at haskell.org
Datum 27.11.2024 10:57:57
Betreff Re: Feedback on potential change in boot library

>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
>
>
>On Wed, Nov 27, 2024 at 08:02:10AM +0000, Adam Gundry wrote:
>>  It's not obvious to me that this is a good idea. Users already complain that
>>  "upgrading GHC broke my code", when in practice this frequently means "when
>>  upgrading GHC I used new boot library versions with incompatible APIs that
>>  broke my code". So having a policy of introducing more frequent API changes
>>  (and making it harder to switch between GHC releases in a single release
>>  series) needs clear justification IMHO.
>>
>>  (Of course in the long term we should make it easier for users to pin boot
>>  library APIs while upgrading GHC independently, but we're not there yet.)
>>
>>  I think that by default, it makes sense for a new minor GHC release to keep
>>  the same API versions of boot libraries, but bump to the latest super-minor
>>  component (i.e. for an A.B.C.D version, keep A.B.C the same but bump D). If
>>  a boot library fixes a bug that is critical enough to require bumping the
>>  version distributed with GHC, ideally there would be an API-compatible
>>  release of the boot library. Of course that might not always be feasible,
>>  and it is ultimately a judgement call for the GHC maintainers as to which
>>  boot library versions are best to ship.
>>
>>  On 26/11/2024 22:27, Hécate via ghc-devs wrote:
>>  >  From the cabal perspective this great news, as this will allow the
>>  > feedback cycle between our two projects to be shorter. Glad to see the
>>  > GHC team is considering this!
>>  >
>>  > Cheers,
>>  > Hécate
>>  >
>>  > Le 26/11/2024 à 21:14, Ben Gamari a écrit :
>>  > > tl;dr. We propose that GHC more aggressively bump its boot library
>>  > >         dependencies.
>>  > >
>>  > >
>>  > > Hello all,
>>  > >
>>  > > Historically, GHC minor releases have been quite conservative in bumping
>>  > > boot library versions, generally defaulting to retaining the versions
>>  > > used in the GHC-x.y.1 release unless
>>  > >
>>  > >   * a request is made by a boot library maintainer, or
>>  > >   * we discover an issue which warrants a bump
>>  > >
>>  > > The motivation for this policy is both to
>>  > >
>>  > >   * minimize the potential for regressions in correctness and
>>  > >     performance, and
>>  > >
>>  > >   * reduce the potential for end-user breakage due to interface changes
>>  > >     as even minor releases can result in considerable impact (e.g.
>>  > >     #25411, #22633)
>>  > >
>>  > > While this policy has served us well, its conservative nature demands
>>  > > the vigilence of both GHC and upstream maintainers to ensure that bumps
>>  > > that are truly necessary do not fall through the cracks.
>>  > >
>>  > > As the flaws of this process have been more apparent recently (e.g.
>>  > > #24597), we have done a bit of reflection on how we might improve the
>>  > > status quo. Concretely, I would like feedback on the adopting the
>>  > > following policy going forward:
>>  > >
>>  > > > Unless guidance is provided otherwise by a library maintainer, a GHC
>>  > > > x.y.z release will attempt to ship the newest minor version of each
>>  > > > boot libray in the same major series shipped with GHC x.y.1.
>>  > > I believe this policy would leave less room for human error and open
>>  > > opportunities for automated checking. On the other hand, the more
>>  > > aggressive bumping of submodules may mean that users are hit with more
>>  > > (usually minor) compatibility issues when moving between minor GHC
>>  > > releases.
>>  > >
>>  > > How do others feel about this? We are particularly interested to hear
>>  > > from boot library maintainers but feedback from packagers and users is
>>  > > also very much welcome.
>_______________________________________________
>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-releases/attachments/20241127/691322c6/attachment.html>