Release checklist for GHC 9.10

[Mikolaj]

Here we track the status of the GHC-related steps for the Cabal release which will ship with GHC 9.10. The previous ticket in this series: #9203. This issue is a part of the https://github.com/haskell/cabal/wiki/Making-a-release process, but this portion of the process is managed jointly by the cabal and GHC team (which should be reflected in who is assigned to it).

• Agree which cabal release is aimed for sync with the GHC release and let GHC include a snapshot of the release branch once it's cut. It's better if it's a major cabal release, but patch release is doable, though we can't perform the steps that break the API and instead we hack around the steps.
• Bump any deps that GHC bumps. Update on master, then backport.
• Make the new GHC a known compiler to cabal by updating setupMinCabalVersionConstraint in cabal-install/src/Distribution/Client/ProjectPlanning.hs. Update on master, then backport.
• Update Cabal/src/Distribution/Simple/GHC.hs to include the new GHC version --- the dozen of lines after "Cabal currently supports" (and sometimes much more, though it's probably not for release managers to do but for PR authors that add support for new major GHC features). Update on master, then backport.
• Update Cabal-syntax/src/Language/Haskell/Extension.hs list, if there are new GHC extensions. Compare with ghc --supported-languages to determine if there are any. Update on master, then backport. There is a test for that (https://gitlab.haskell.org/ghc/ghc/-/blob/master/testsuite/tests/driver/T4437.hs) that the GHC team runs in CI for their new GHC branch, so we can ask the liaison if it's green and if it stays green when GHC is being finalised.
• Add a new language version GHCXXXX, if any, e.g., Support GHC2024 (fixes #9736) (backport #9791) #9880. Update on master, then backport.
• Add any new GHC flags (I don't remember whether they are used to determine recompilation only or anything else?). This involves (amounts to?) updating normaliseGhcArgs in Cabal/src/Distribution/Simple/Program/GHC.hs and adding the new GHC version to supportedGHCVersions in the same file. Update on master, then backport. This one point can be postponed to the first patch release if we are sure there's going to be one.
• Add the new GHC to CI (this always causes problems; we haven't recovered from CI Windows segfaults on 9.6 yet, I think, so in practice this unfortunately often gets postponed). Update on master, then backport.
• Ask the GHC liaison whether T4437 is green for the last time (or check in GHC CI manually).
• When we tag Cabal the library for release (with Cabal-syntax), give the final realease git tag (not commit) to the GHC devs for inclusion in GHC. Ideally, that cabal version would be on Hackage before the GHC ships.

Here's an old ticket for coordinating manual testing with a new GHC: #8026. It's useful if we don't have the new GHC in CI before cabal release. If we decide to run the equivalent of CI runs manually before release, let's clone this ticket and report in it how the runs go.

[Mikolaj]

A related ticket about silencing a warning that made much more sense in the old process, where Cabal was released after the corresponding GHC release: #9734 (now Cabal is supposed to be released before).

[Mikolaj]

@bgamari: we are nearing Cabal+Cabal-syntax release as 3.12.0.0. How are things standing with GHC 9.10? Any new extensions since we last spoke? Could you perhaps check some of the boxes?

[bgamari]

Unfortunately 9.10 has been off to a rocky start at best. However, I am presently in the process of announcing alpha 1. Currently the ghc-9.10 branch sits on Cabal commit fb3f4d4 and there are no GHC-only language extensions indicated by T4437.

[bgamari]

The flags introduced in GHC 9.10 include:

• -finfo-table-map-with-stack and its inverse
• -finfo-table-map-with-fallback and its inverse
• -forig-thunk-info and its inverse
• -fbreak-points
• -fdiagnostics-as-json
• -fprint-error-index-links
• -fprof-late-overloaded
• -fprof-late-overloaded-calls
• -fdo-clever-arg-eta-expansion
• -fkeep-auto-rules
• -fpolymorphic-specialisation
• -fspecialise-incoherents
• -Wincomplete-record-selectors
• -Wdeprecated-type-abstractions
• -Wbadly-staged-types
• -Winconsistent-flags
• -Wdata-kinds-tc
• -Wdefaulted-exception-context
• -dipe-stats
• -ddump-dmdanal
• -ddump-dmd-signatures
• -ddisable-js-c-sources

[Mikolaj]

Thanks a lot for the news, Ben. @Kleidukos, @ffaf1: maybe we can do the GHC flags update in the 3.12.1.0 release that includes cabal-install? IIRC the flags are mostly needed to determine whether to recompile. I'm assuming adding the flags does not change the API, as opposed to adding extensions or licences, so it can be postponed. I think flags have not been updated since a few GHC versions, which is why the list is so long (and we need to double-check if it's not longer).

[bgamari]

How are things looking here? At this point we are less than a month from the 9.10.1 release candidate; it would be good to start firming up a plan for release.

[ffaf1]

Hello @bgamari, 3.12 release is progressing, albeit a bit slow because of some ambiguity in the release documentation.

My aim is get this sorted before next cabal call (so in slightly less than two weeks), I am positive I can wrap this up before that date.

[ulysses4ever]

@Mikolaj thanks for assigning me! Could you remind me what I'm supposed to do 😊

[Mikolaj]

@ulysses4ever: not much, since you coordinate a patch release, but there will be a couple of points not done after 3.12.0.0 is released, so it will be for you to decide whether to implement them and, if so, to coordinate the effort.