Recommend GHC 9.10.3 ?

[andreasabel]

For GHC 9.8, no more releases are planned, so 9.8.4 will be last in the series:

• https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
• https://endoflife.date/ghc

Also Stackage seems to have closed the LTS for 9.8, with LTS-23.28 being the last. (@juhp Please correct me if I am wrong.)

Can the recommended GHC version be bumped from 9.6.7 to 9.8.4 or are there any obstacles to this?

[mpilgrem]

@andreasabel, you can be confident that there will not be another LTS for GHC 9.8.4. If there ever was a GHC 9.8.5, it is not certain that there would be an LTS for it. However, we had, in recent experience:

2024-11-24 LTS 22.43 (GHC 9.6.6)
2024-12-09 LTS 23.0 (GHC 9.8.4) (The first in the GHC 9.8 series)
2025-03-24 GHC 9.6.7
2025-05-02 LTS 23.21 (GHC 9.8.4)
2025-05-02 LTS 22.44 (GHC 9.6.7)

[juhp]

Well Stackage hasn't formally "closed" LTS 23 yet, though it's hard to say if (or when) there might be another point release. Our focus is on LTS 24 now and sooner or later LTS 25. (I would say another LTS 22 release is very unlikely at this point.)

The latest/last was https://www.stackage.org/lts-23.28 (17th Aug).

Anyway not sure how much bearing it has on the ghcup default, but I agree completely that lts-23 is very stable by now. And soon there will be ghc-9.14: I personally increasingly believe we should try to encourage adoption of newer GHC's going forward to reduce this endless long version tail (other ecosystems do this well: rust and lean4, etc). Fedora 43 will finally ship 9.8 default soon. 9.8 does have an issue with 32bit (ix86) though (Unique Word64) - dunno if Julian intends to jump straight to 9.10 which is also quite stable in my mind now and 9.10.3 was recently out.

https://repology.org/project/ghc/versions

[ulysses4ever]

nixpkgs is on 9.8 now and will move to 9.10 real soon (hopefully, with nixos-25.11 slated to appear at the end of next month).

[hasufell]

9.6 is a de facto LTS with lots of backports done by @luite.

Since GHC is now officially moving to an LTS model, I'd be inclined to have recommended follow that.

But I have not received further insights on those plans.

@AndreasPK @bgamari

[AndreasPK]

If it's between 9.8 and 9.10 I would recommend 9.10,. As one might expect we already fixed a number of issues since the release of 9.8.4, many of which have been backported to 9.10.3 but remain in 9.8.4.

But I have not received further insights on those plans.

There have been no changes or new insights to share since the announcement and our discussions at zurihac. 9.14 will be the next/first LTS. Ben is working on ironing out the last few issues that apple gifted us to unblock the release.

Is there anything that's unclear or that you could use insights on?

---

Personally I would suggest skipping 9.8 and recommending 9.10 in the near future. And then recommending 9.14 after it's been out for a few months and then following the LTS branches.

9.10 already has been out for a while. And there will be one more minor release for it hopefully allowing us to include fixes for all bugs found in the next few moths. So I don't thinks it's a particularly risky choice.

[fendor]

There seems to be some issue with HLS to be present in GHC 9.10 (and perhaps 9.12?) series: haskell/haskell-language-server#4674
I am not sure how often this occurs in practice, but might be a blocker for recommending 9.10.

[fendor]

@AndreasPK and I investigated the bug in haskell/haskell-language-server#4674.
It seems, the bug is caused by hls-hlint-plugin using ghc-lib-parser-9.12 on ghc-9.10.
ghc-lib-parser and ghc share the same FastStringTable so it is of crucial importance, that both agree about the implementation.
Due to changes to GHC.Data.FastString, these versions are not compatible and the result is a rather difficult to diagnose crash.

I validated this, by building ghc 9.10.3 from source and applying the changes to the FastStringTable from 9.12 to 9.10.
When applying this change, the seg fault is no longer reproducible.

The solution is that we disable the hls-hlint-plugin for ghc-9.10.
This makes sense, as hlint itself doesn't even support ghc-9.10.
The next HLS release will remove the hls-hlint-plugin for ghc-9.10 releases.

If this is satisfactory to everyone, we could recommend ghc 9.10 from the next HLS release onwards.
The next HLS release is planned to coincide with GHC 9.12.3 or GHC 9.14, although I am not 100% sure which will happen first or whether they happen within the same week.

[Bodigrim]

@fendor shall we revise ghc-lib-parser to eliminate incompatible configurations?

[fendor]

yeah, I think that sounds sensible!

[Bodigrim]

yeah, I think that sounds sensible!

Could you clarify, is ghc-lib-parser-9.12 always broken when compiled by GHC 9.10? Or is it just incompatible when used in conjunction with ghc-9.10-the-library?

[AndreasPK]

Could you clarify, is ghc-lib-parser-9.12 always broken when compiled by GHC 9.10? Or is it just incompatible when used in conjunction with ghc-9.10-the-library?

I think the later. Upstream ticket is digital-asset/ghc-lib#620

[juhp]

I thought it was only possible to build ghc-lib*-X.Y with ghc-X.Y ?

[Bodigrim]

@juhp ghc-lib-parser is more flexible, say, you can build ghc-lib-parser-9.14 with GHC 9.12.