Open Mikolaj opened 4 months ago
The PR that introduced the warning is https://github.com/haskell/cabal/pull/5194/files and it links to the issue with a good discussion why such a warning is needed, which is the only reason I don't argue for removing it altogether.
But maybe we should remove the warning, after all, to decouple GHC and Cabal more? A welcome side-effect would be one less code change in the ever-growing Cabal release checklist. But ideally this would be a deep decoupling, removing the need for the warning rather than the warning alone. Has anything changed, except the release process, that makes the warning less important? Any API compatibility guarantees/checks elsewhere?
Here's the warning
https://github.com/haskell/cabal/blob/3a275e5c7758372780fb1ad3247aa7c2d1297d31/Cabal/src/Distribution/Simple/GHC.hs#L164-L174
The rationale is that our release sync method with GHC releases has changed and now Cabal is supposed to release a new version before GHC releases theirs and so we can't easily test that the new GHC works fine with the new cabal release. What we and the fine GHC folk can do is analyse the API and make the best effort and then be on a lookup for problems. That makes this warning much weaker than it was before (or rather, the lack of the warning gives much weaker guarantees than if GHC was in CI before the warning is enabled for a given GHC version). So I'd propose to show it only at verbosity one notch higher than the default. We also had a case where we needed to do a lightning fixup release only to silence the warning, because it's so spammy and that's not a good use of cabal maintainer time and sanity.
Thoughts? Related: https://github.com/haskell/cabal/issues/9729