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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
