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.

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).

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?

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.

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.

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.

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

#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.

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?)

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.

Rebased on master now, too.

• 9.10.2 regression: https://gitlab.haskell.org/ghc/ghc/-/issues/25056
• 9.10.1 also still has text 2.1.1 which is not affected by CRLF with BlockBuffering not always correct haskell/text#648

Didn't look for 9.12 yet which probably also has seen less exposure to real world usage.

In my experience, it takes some minor versions until GHC “settles down”, so to speak and this can take quite a while. 9.4 and 9.2 got up to .8 for a reason. It is also not uncommon for subsequent minor releases to introduce regressions unfortunately. 9.8 was pretty good in this regard, so let's hope 9.10 and 9.12 are similar.

Rebased over the addition of GHC 9.10.3. Also added a commit to drop GHC 9.10.2 - although that's technically not covered by the GHC Deprecation Policy, yet, because there is no Stackage release for it.

I assume the addition of GHC 9.10.3 doesn't change anything wrt the drop of GHC 9.10.1, so still keeping as draft for later.

It seems to me that we should review before branch off which compilers from 9.10/9.12 we can drop. It would be nice to reduce the number a little bit.

The issues I was aware of with 9.10.2 have been resolved in 9.10.3. Not sure if there are any problems, maybe on non x86_64-linux?

9.10.3 seems to have a regression related to ARMv7 cross‐compilation, at least when using aarch64-linux as the build platform; see the commit message of 94873dc for details. 9.10.2, 9.12.1, and 9.12.2 all succeed, so it’s just that one version that has issues. I assume it just needs a fix backporting from 9.12.1 or a bad backport reverting, but I haven’t bisected or even looked at the commit log.

Probably one of:

• https://gitlab.haskell.org/ghc/ghc/-/commit/23789c2839fe403c085161b1dbbd762932750881
• https://gitlab.haskell.org/ghc/ghc/-/commit/0b4316fdc37cfd4f01e989e306991b3a5bf47002
• https://gitlab.haskell.org/ghc/ghc/-/commit/4cc84ccffb2928af3a9bf3ea6d0262684ac454d4

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.

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.

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

I pushed the 9.12.1 drop onto haskell-updates already.