haskell.compiler.ghc{9102,9122}: drop

[wolfgangwalther]

Drops all GHC minor versions that are currently:

• Not the latest minor version of the respective major version, and
• Not the latest version in a stackage major, and
• Not used for bootstrapping others (GHC 9.6.3 is used to bootstrap GHC 9.6.7, so can't drop that)

This applies our Deprecation Policy. Removal of GHC minor version has so far not appeared in Release Notes, so not adding these here either.

9.4, 9.6 and 9.8 drops already merged.

Things done

• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[sternenseemann]

I think 9.10.1 and 9.12.1 may be a little premature. That release series doesn't really have a “finished” version yet where all the mayor regressions have been addressed, so it may be better to give the users all reasonable options.

[wolfgangwalther]

I think 9.10.1 and 9.12.1 may be a little premature. That release series doesn't really have a “finished” version yet where all the mayor regressions have been addressed, so it may be better to give the users all reasonable options.

If that's something we consider, then we should put that down in our policy. Currently the policy doesn't say anything about that (and I don't particularly buy into the argument either).

[wolfgangwalther]

That release series doesn't really have a “finished” version yet where all the mayor regressions have been addressed

If we want to put something like that into the policy, how could we word it? Is there a way to determine whether a version is "finished"?

One way to do it would be to essentially say "we'll keep all minor versions for GHC major versions that are still under active development" or so?

[maralorn]

I don’t think it necessarily has to be in the policy. I see the policy as giving us permission to remove them.

I like this PR very much, no matter what we do with 9.1{0,2}. On that issue I would tend to say: Let’s drop them unless we know of a specific regression from 1X.1 to 1X.2.

[wolfgangwalther]

Let’s drop them unless we know of a specific regression from 1X.1 to 1X.2.

@sternenseemann do you know of any specific regression for eiher .2 release?

I see it like this:

• IIRC, 9.12.1 was problematic, it had serious problem. I don't remember the details, but I think it was advised against using it? If we can't recommend 9.12.1, we can as well drop it.
• 9.10.3 is close to being released + we are working specifically on 9.10.2 as the default compiler right now. Having 9.10.2 as the default version gives us a much better idea of whether there are problems specific to that version, because we're building all of haskellPackages on it. Thus, the specific need for 9.10.1 seems very low - and it's very unlikely that anyone will want to downgrade from the default 9.10.2 / 9.10.3 to 9.10.1, having to rebuild everything when they could use the cache just as well.

If you still think this is controversial and would rather not drop these versions, I can ofc remove these commits from the PR, so that we can proceed with the others at least.

[wolfgangwalther]

I merged the uncontroversial changes for GHC 9.4.x, 9.6.x and 9.8.x to haskell-updates already. This PR now only contains the changes to GHC 9.10.x and 9.12.x.

[emilazy]

#440410 (comment) seems like a concrete reason to drop 9.10.1.

[wolfgangwalther]

#440410 (comment) seems like a concrete reason to drop 9.10.1.

Since I changed two parameters between failure and success, it could technically also be unrelated to GHC 9.10.1.

[emilazy]

Fair enough. Although the arguments for keeping it seem sufficiently weak that “saving having to do another build to test whether it is actually blocking something” is enough for me, personally 😅

(This can target master too?)

[wolfgangwalther]

Fair enough. Although the arguments for keeping it seem sufficiently weak that “saving having to do another build to test whether it is actually blocking something” is enough for me, personally 😅

I certainly agree on that.

(This can target master too?)

Yes, waiting with the rebase until some of the other stuff is merged, because multiple of these PRs will create conflicts anyway.

[wolfgangwalther]

Rebased on master now, too.

[wolfgangwalther]

I rebased this branch. If everything looks good, I would cherry-pick the first commit, i.e. the removal of GHC 9.12.1, to haskell-updates already.

We can then figure out if and what to do about the cross-compilation issue for 9.10.3 and whether we will drop 9.10.2 or not.

[emilazy]

Perhaps we should just split this into two PRs, since dropping 9.12.1 seems uncontroversial? It looks good to me. But of course if you want to push the commit directly that seems fine as well.

[emilazy]

Wow, 9.12.1 truly is busted: https://gitlab.haskell.org/ghc/ghc/-/issues/25653.

[wolfgangwalther]

I pushed the 9.12.1 drop onto haskell-updates already.

[wolfgangwalther]

It seems to me that we should review before branch off which compilers from 9.10/9.12 we can drop.

Next branch off coming up in a month or so - therefore picking up the discussion again. Kept the drop for 9.10.2 and added the drop for GHC 9.12.2 as well. These are the minor version drops we should do right now according to the GHC Deprecation Policy.

The only major version that could be dropped according to the policy would still be 9.4. The 9.6+ TH problem is solved now, but I guess we'll still want to keep 9.4 for cross-compiling reasons.

[sternenseemann]

The only major version that could be dropped according to the policy would still be 9.4. The 9.6+ TH problem is solved now, but I guess we'll still want to keep 9.4 for cross-compiling reasons.

Yes. As things stand I think 9.6 should be the next major version we remove (wasn't a very good version anyways), though our old friend Elm depends on that at the moment unfortunately.

I am not aware of any problems with 9.10.3 since we've discussed it last. #439323 (comment) is probably not reason enough to keep it around on the stable branch.

9.12 is really in a sad state, but 9.12.3 is seems very usable since we've patched the miscompilation. 9.12.4 can't really compile profiling objects without crashing which is very unfortunate for us. It's apparently not a given that there will be a 9.12.5 and a fix for the profiling crashes is still pending for master last I checked. I'm unsure whether backporting that when it materializes or reverting stuff from the 9.12 branch will be the best course of action.

[guibou]

9.12 is really in a sad state, but 9.12.3 is seems very usable since we've patched the miscompilation. 9.12.4 can't really compile profiling objects without crashing which is very unfortunate for us. It's apparently not a given that there will be a 9.12.5 and a fix for the profiling crashes is still pending for master last I checked. I'm unsure whether backporting that when it materializes or reverting stuff from the 9.12 branch will be the best course of action.

Note that 9.12.4 (and 9.14) also contains a bug in the RTS which could randomly crash / deadlock, see https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15640. So better to keep 9.12.2 or 9.12.3, but avoid 9.12.4 for now.

[wolfgangwalther]

So better to keep 9.12.2 or 9.12.3, but avoid 9.12.4 for now.

This PR keeps 9.12.3, which is the default for 9.12 for us right now anyway. It only drops 9.12.2.

[wolfgangwalther]

As things stand I think 9.6 should be the next major version we remove (wasn't a very good version anyways), though our old friend Elm depends on that at the moment unfortunately.

Right. According to our policy, we can only remove 9.6 once we updated the default version to 9.12 anyway, so certainly not for 26.05.

I understand everything else you wrote essentially as an approval of this PR.