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.
Cheers,
Adam
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.
Cheers,
- Ben
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
