Priorities for upcoming GHC releases

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.

13 Likes

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.

3 Likes

So I guess that means both ghcup and stack should target 9.6 and 9.10 for their “recommended” versions/LTSes?

3 Likes

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

1 Like

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.

1 Like

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

3 Likes

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

  • In Section 0 follow the link to the GHC Release Status Page
  • That page tells you to follow the link to the milestone for 9.12. When you do that you’ll find dates.

Does that help?

Simon

1 Like

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.

2 Likes

Could you explain the situation here? I don’t understand.

1 Like

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.

1 Like

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.

6 Likes

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.

2 Likes

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.

1 Like