Mikolaj Konarski
Mikolaj, what’s the schedule for Cabal 3.12?
I've opened a ticket for the 9.10 cabal and GHC sync point: https://github.com/haskell/cabal/issues/9729
Whom should I assign from outside the cabal team?
BTW, is the list of new GHC 9.10 language extensions finalized? How about GHC options? Would somebody like to see if the cabal's list of of GHC options is up to date (I bet it's not), and which of them require a recompilation? The same for extensions (but the list should be up to date except for the newest extensions --- are they all listed in 9.10 Release Notes this time?). PRs are welcome (one is already in the merge queue, but I'm not sure if it's for GHC 9.10: https://github.com/haskell/cabal/pull/8854).
The only new extension which has yet to be merged is indeed ListTuplePuns. Otherwise the T4437 test, which tests the consistency of GHC's and Cabal's respective language extension sets, doesn't indicate any new extensions in GHC.
all major releases should be reflected as submodules in GHC source tree before GHC fork date
Am I to understand that the cabal-GHC sync should proceed differently this time and a cabal release is expected before the GHC release?
To clarify, this has been the hope in the past as well. However, things rarely worked out that way.
That should be fine, but the semantics of cabal's GHC version validation would change from "the GHC is tested and known to work fine with cabal" to "the GHC exists".
The expectation is that after the fork only bug-fixes will be committed. Naturally there is always a bit more churn directly after the fork happens, but I don't expect, e.g., any major new language extensions to be introduced.
If so, maybe we should altogether remove the spammy "unknown GHC version" cabal warning, decoupling cabal and GHC a bit as a welcome side-effect?
In general I am in favor of more decoupling. However, whether the "unknown GHC version" warning should be removed is something that we should likely discuss on a ticket. Cheers, - Ben