We detail our plans for upcoming GHC releases in a new blog post:
https://www.haskell.org/ghc/blog/20240521-ghc-release-priorities.html
The summary is that we will prioritise work on the 9.10, 9.6 and master branches over work on the 9.8 branch for the coming few months due to time and resource constraints. This does not mean that we are dropping support for GHC 9.8, but that releases in this series might be made at a slower pace than usual.
Thanks for making this explicit! While this will not impact libraries supporting 9.8 (at least mine), this will certainly help big applications when deciding which GHC to support.
So I guess that means both ghcup and stack should target 9.6 and 9.10 for their ârecommendedâ versions/LTSes?
When do you plan to release GHC 9.8.3?
I am asking on behalf of the Stackage team, since we are wondering when to release Stackage LTS 23 (currently Nightly is still on 9.8 and around the same time we would want to move it to 9.10, I think).
When do you plan to release GHC 9.8.3?
There is no planned release date yet, but it will be after 9.10.2 which should be released in the next month.
How do the plans outlined in this blog post interact with the release of GHC 9.12.1? I tried looking at the milestones page to get an idea of what the current priority is, but I was not able to tell.
Is there an official place for the release schedule? I am asking because it sounds like a concept of âplanned release dateâ does exist (just not for 9.8.3 yet). It would be useful for planning purposes, if e.g. I want plan testing of my software with the new release.
Is there an official place for the release schedule?
Indeed there is: Glasgow Haskell Compiler / ghc-hq ¡ GitLab
Looking at it, the 9.12 release looks scheduled for Nov 24, though the intermediate dates are all TBA. Does that help at all?
Simon
Hi Simon, I wasnât able to find any dates by following your link. Is it the one you meant to post?
GHC Status ¡ Wiki ¡ Glasgow Haskell Compiler / GHC ¡ GitLab is a promising candidate, but also has no dates for future releases.
The dates for 9.12.1 are on the milestone page: 9.12.1 ¡ Milestones ¡ Glasgow Haskell Compiler / GHC ¡ GitLab
Yes itâs the âroot pageâ I always start from. I should have elaborated
Does that help?
Simon
Yes, I got as far as the milestone page and then completely overlooked the large subsection âTentative release schedule.â My fault!
From the Stackage point of view, we are still waiting for 9.8.3,
and I think there are also other people waiting for Cabal to be updated in 9.8.
(If possible it would really be better to avoid this situation where a library
is ahead in an older ghc major version like we have now for Cabal,
specially for an extended period: that would be best software engineering practice.)
So I do wonder if it wouldnât make sense to prioritize a 9.8 release first before 9.10 at this point.
(Though I donât know how near you are to releasing 9.10.3.)
Also it would be helpful if someone could outline the main problems with current 9.8(.2) and to what extent if any they would be addressed in 9.8.3.
Could you explain the situation here? I donât understand.
Nixpkgs is also waiting. From what I could gather itâs not even clear a new 98 release was supposed to be happening at all and if it were, then after 910 and 912.
Thereâs a bug in Cabal 3.10.2 that affectâs users of the Setup commands and libraries which need GHC plugins.
Stack
Cabal
Nixpkgs
The fix is in 3.10.3
I will discuss the plans for a 9.8.3 release with the team. Currently we are a bit busy with the 9.12 fork.
My intuition tells me GHCup will likely skip the 9.8 branch in terms of ârecommendedâ releases. 9.6 is still busted on FreeBSD. I hope GHC developers will investigate that at some point.
I thought you knew that FreeBSD was not a supported architecture for 9.6. GHC developers donât have the capacity to fix it. I know this is likely to trigger more hard feelings, but somehow we need to reach an understanding that FreeBSD is not supported for 9.6, 9.8, 9.10, and 9.12 because of a lack of resources. There is no alternative. This has simply already happened. Itâs history.
Your refusal of this reality frustrates me because your GHCup defaults negatively effect adoption of new versions of GHC. This makes it likely that bugs are going uncaught, and it wastes GHC developer time: the amortized cost of a release goes up if fewer people use it.
What will it take to move past this impasse?
Are you saying contributions to fix less supported platforms are not welcome? Iâm not sure thatâs what I got from GHC devs.
Iâve been asking knowledgeable people to investigate and it appears thereâs already a solution to fix that specific bug.
I have communicated this to the Haskell Foundation as well.
GHC should be a collaboration effort and the resources of one company contributing to it shouldnât be the last word (and I donât think thatâs how GHC HQ sees itself).
We will see how we can facilitate better FreeBSD support. I donât believe that it takes that much effort to keep it alive in an ânot officially testedâ fashion.
I think thatâs somewhat untrue.
New GHC versions become available in GHCup almost right away. I have carried out this work since 2019 (mostly on my own, unpaid) and the longest delay has probably been 3 weeks when my laptop was in repair.
If youâre talking about the recommended version, then I have to disappoint and explain (again) that the purpose is NOT to distribute the latest versions.
I have explained the trade offs involved at the haskell foundation workshop, but one major use case is: a student course of 200 students. They likely donât care at all about the new language features, linear types or the new JS backend. They need a consistent installation experience throughout all platforms.
Having some of their solutions crash at runtime due to an rts bug seems like an awful UX.
That is why I will continue to push for better platform support on FreeBSD.