Feedback on potential change in boot library

[Tom Ellis]

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.