# Please revise GHC release policy

**URL:** <https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158>\
**Category:** Links\
**Created:** [May 24, 2025, 1:19am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158 "2025-05-24T01:19:51Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![arybczak](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/arybczak/32/2527_2.png) [@arybczak](https://discourse.haskell.org/u/arybczak)\
**Post date:** [May 24, 2025, 1:19am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/1 "2025-05-24T01:19:51Z")

</div>

I posted this on the GHC tracker, but giving a link here for more visibility: [#26067: Please revise the release policy · Issues · Glasgow Haskell Compiler / GHC · GitLab](https://gitlab.haskell.org/ghc/ghc/-/issues/26067)

Basically, it looks to me that the current release policy serves no one (developers have to spend tons of time backporting bugfixes to multiple branches, while users are getting confused about which recent major release to pick, while these releases can lag behind HEAD wrt. bugfixes for a long time) and revising it to have less major version releases and more minor (bugfix) releases would be a substantial improvement.

---

<div class="post-metadata">

**Author:** ![Ambrose](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ambrose/32/5672_2.png) [@Ambrose](https://discourse.haskell.org/u/Ambrose)\
**Post date:** [May 24, 2025, 3:28am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/2 "2025-05-24T03:28:05Z")

</div>

Doesn’t this hold up new extensions and features? This feels like a change purely from a maintainer/stability advocate standpoint.

Not saying anything about the current process (I am pretty apathetic to it atm).

Maybe we need an ongoing stable major version and unstable major version. The unstable one accumulates new stuff (without considering compat - it’s unstable) until it crystallizes into the next stable version on some schedule. You release what you have, more or less.

Maybe that’s how it already works but faster?

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [May 24, 2025, 4:12am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/3 "2025-05-24T04:12:09Z")

</div>

> Doesn’t this hold up new extensions and features?

Those new extensions and features may as well not exist if the system that provides them is about as stable as quicksand.

Innovation relies on stability:

- just as ship-building relies on the stability of dry docks (or other land-based infrastructure), or sheltered harbours (in the case of mobile/floating dry docks).

- or tall buildings in cities, where each new floor is constructed when the current (top) floor is sufficiently stable.

As for software, it’s so much easier to _“innovative”_ when all of the dependencies have been stabilised. So yes:

- this **_is_** a change from a maintainer/stability advocate standpoint,

- **_but_** those who _“innovate”_ will also benefit from it.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [May 24, 2025, 4:41am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/4 "2025-05-24T04:41:59Z")

</div>

> [@Ambrose](#):
>
> Doesn’t this hold up new extensions and features?

For experimental purposes, maybe, but not for proper use… given that many people these days seem to skip one or two releases anyway before they upgrade their codebases.

For those experimental purposes, there are other solutions (such as nightlies).

---

<div class="post-metadata">

**Author:** ![therivercass](https://avatars.discourse-cdn.com/v4/letter/t/d6d6ee/32.png) [@therivercass](https://discourse.haskell.org/u/therivercass)\
**Post date:** [May 24, 2025, 5:16am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/5 "2025-05-24T05:16:55Z")

</div>

doing the painful thing less frequently doesn’t improve stability. we should be asking “why is it painful? how can we improve those things?” deferring the pain makes it worse, not better – you’re taking on a larger change, after all.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [May 24, 2025, 5:44am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/6 "2025-05-24T05:44:49Z")

</div>

Every release, even if minor, requires **attention** from the whole ecosystem:

- GHCup
- Stack/Stackage
- Cabal (it’s intertwined with GHC)
- HLS
- Library developers and hackage trustees (upper bounds, breaking changes, etc)
- application developers

In addition, we have significant mental/decision overhead now regarding the question “which GHC branch should I pick?”.

Less frequent major releases remove some of the work for library/application developers and requires less work for HLS to adapt to the otherwise constantly changing GHC API. But for distributors, it makes little difference: my work load is almost the same, no matter if it’s a minor or major release. Stackage certainly has it a bit easier on minor updates, though.

My hope is that less frequent major releases also positively impact the **release quality** and as such there’s also less need for constant minor updates. I’m not sure if that’s realistic.

* * *

I just wanted to point out that 3 breaking changes distributed over 3 releases still requires more work/attention than 3 breaking changes in one release.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [May 24, 2025, 5:46am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/7 "2025-05-24T05:46:35Z")

</div>

Moreover, the problem here isn’t _“pain”_, but _“context switches”_ - it takes the average human brain almost half an hour to re-establish it’s concentration on a task after being interrupted. So dealing with lots of small breaking changes costs more in mental effort than a few large changes.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [May 24, 2025, 8:24am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/8 "2025-05-24T08:24:43Z")

</div>

> [@hasufell](#):
>
> For […] experimental purposes, there are other solutions (such as nightlies).

…or just providing regular (compressed) snapshots of GHC’s _“cutting edge”_ sources: experimenters can then test the build system as well as the compiler.

---

<div class="post-metadata">

**Author:** ![TeofilC](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/teofilc/32/3987_2.png) [@TeofilC](https://discourse.haskell.org/u/TeofilC)\
**Post date:** [May 24, 2025, 9:10am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/9 "2025-05-24T09:10:49Z")

</div>

> [@hasufell](#):
>
> Every release, even if minor, requires **attention** from the whole ecosystem:
> 
> - GHCup
> - Stack/Stackage
> - Cabal (it’s intertwined with GHC)
> - HLS
> - Library developers and hackage trustees (upper bounds, breaking changes, etc)
> - application developers

I think this is a valid point, but incompatible with your suggestion that people should use nightlies instead of having 6-monthly releases.

> [@hasufell](#):
>
> For those experimental purposes, there are other solutions (such as nightlies).

For nightlies to be usable, they should have support from the ecosystem including the things you list.

Currently that is rarely the case.

So if we wanted to switch to a model where we have fewer major releases but nightlies were a viable option that would increase the amount of work necessary as the ecosystem would continually have to keep up with nightlies.

That is not to say we shouldn’t use nightlies more. I think we should but it will take work.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [May 24, 2025, 9:40am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/10 "2025-05-24T09:40:55Z")

</div>

> [@TeofilC](#):
>
> I think this is a valid point, but incompatible with your suggestion that people should use nightlies instead of having 6-monthly releases.

I beg to differ. But I was a bit handwavy.

First, nightlies have to be supported properly in GHCup, second we need a way to opt out of breaking changes of the latest compilers. There are multiple attempts at doing that, such as base split and language editions.

So you would get access to experimental compiler features right after they have been merged and may use it on parts of the ecosystem. But you don’t get guarantees that those experimental features will make it in that shape (or at all) into a proper release.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [May 24, 2025, 10:02am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/11 "2025-05-24T10:02:24Z")

</div>

> [@hasufell](#):
>
> […] we need a way to opt out of breaking changes of the latest compilers. There are multiple attempts at doing that, such as base split and language editions.

If only we did have [Rust-style (language) editions](https://doc.rust-lang.org/edition-guide/editions/index.html) (as opposed to whatever [this](http://discourse.haskell.org/t/seeking-feedback-on-language-editions-proposal/8780) was supposed to be)…but we don’t. However I think the breakup of `base` is still going.

---

<div class="post-metadata">

**Author:** ![TeofilC](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/teofilc/32/3987_2.png) [@TeofilC](https://discourse.haskell.org/u/TeofilC)\
**Post date:** [May 24, 2025, 10:06am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/12 "2025-05-24T10:06:44Z")

</div>

> [@hasufell](#):
>
> First, nightlies have to be supported properly in GHCup, second we need a way to opt out of breaking changes of the latest compilers. There are multiple attempts at doing that, such as base split and language editions.

I think things like that will make both new nightlies and major releases less work to support for the ecosystem, and that would be great!

HLS for instance depends quite a bit on the GHC API and I’m a bit sceptical we will ever get to a stage where it won’t often break with nightlies. `ghcide` is included in `head.hackage` and it breaks pretty often.

---

<div class="post-metadata">

**Author:** ![juhp](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/juhp/32/323_2.png) [@juhp](https://discourse.haskell.org/u/juhp)\
**Post date:** [May 24, 2025, 10:48am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/13 "2025-05-24T10:48:25Z")

</div>

I agree with the filed issue, however some kind of design needs to be carefully hashed out.  
It is not that easy, but surely we can come up with something better than the status quo.

Thinking in terms of Stackage a maximum of 2 stable maintained major releases should be sufficient I reckon. Ideally I would prefer to see just one stable major version, but that feels so far from where we are currently that it is probably not realistic in the short time.

An idea: something like do a major stable release each year ahead of Zurihac and an unstable major alpha/beta pre-release before ICFP (or vice versa?). In between there could be alternating bimonthly or quarterly minor releases or something like that. The sequence of quarterly RC’s would then culminate in the stable major release the following year.

I have even been pondering whether we could add an `experimental` channel (stream) to Stackage (ahead of nightly): ie currently that would be 9.12, before it moves to nightly.

---

<div class="post-metadata">

**Author:** ![michaelpj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/michaelpj/32/417_2.png) [@michaelpj](https://discourse.haskell.org/u/michaelpj)\
**Post date:** [May 24, 2025, 11:17am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/14 "2025-05-24T11:17:48Z")

</div>

> doing the painful thing less frequently doesn’t improve stability. we should be asking “why is it painful? how can we improve those things?” deferring the pain makes it worse, not better – you’re taking on a larger change, after all.

I strongly agree with this. Slowing down seems unlikely to help. I think there are quite a selection of different problems depending who you are, and the remedy may be different. @hasufell has a good list.

> GHCUp/Stack/Stackage/Cabal/HLS

_Mostly_ per-release busy-work where it doesn’t matter so much whether it’s a major or minor one. Sometimes tricky code changes, but indeed perhaps better to front-load these. HLS has a lot of dependencies, so it’s also has some of the “library developer” problems.

> Library developers and hackage trustees (upper bounds, breaking changes, etc)

My belief is that almost all of this is about _library_ changes, not changes to GHC the compiler. So the thing I’m excited about here is the ongoing work to decouple the version of `base` (and `template-haskell`) from GHC.

> application developers

Here I think the question is mostly “do my dependencies work?” (previous point), and “is the compiler buggy?”. The fact that a lot of the major compiler versions are buggy is definitely a problem. Here I do think we could benefit from having LTS compiler versions. Empirically, it seems to take a while to find all the bugs and backport fixes: LTS versions give time for that process to happen. It’s not just us - it’s true for the Linux kernel as well!

This might also help with the amount of release work for GHC devs. If people mostly care about backports to the LTS branch, perhaps you can get away with having fewer active releases.

> In addition, we have significant mental/decision overhead now regarding the question “which GHC branch should I pick?”.

Again, a LTS compiler would help with this.

Perhaps “frequent releases + LTS” is in practice similar to “infrequent releases + nightlies”. Personally I think the former is a bit easier to understand.

---

<div class="post-metadata">

**Author:** ![TeofilC](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/teofilc/32/3987_2.png) [@TeofilC](https://discourse.haskell.org/u/TeofilC)\
**Post date:** [May 24, 2025, 11:51am UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/15 "2025-05-24T11:51:50Z")

</div>

> [@michaelpj](#):
>
> The fact that a lot of the major compiler versions are buggy is definitely a problem. Here I do think we could benefit from having LTS compiler versions.

My feeling is that there are often bugs in new versions of GHC that only turn up when GHC gets tested against large codebases or a large percentage of the ecosystem. We need to find, fix and release fixes for these bugs before a version of GHC can become “stable”.

Yet, I think often users are unwilling to upgrade until a version becomes “stable”. And so the discovery of bugs is delayed.

I can imagine a longer support window making this situation worse if we aren’t careful.

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [May 24, 2025, 12:11pm UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/16 "2025-05-24T12:11:20Z")

</div>

> [@michaelpj](#):
>
> Slowing down seems unlikely to help.

_shrug_ Definitely would help me and other people in the thread. First bring release cadence in line with community resources, then figure out and implement whatever “stability” improvements you want, then ask unpaid volunteers maintaining vital parts of infrastructure if they would like to increase cadence. Not vice versa.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [May 24, 2025, 12:25pm UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/17 "2025-05-24T12:25:33Z")

</div>

I think it would be helpful to understand which parts of the post-release workflow explained in a previous discussion of this topic are not amenable to automation in principle, and which are amenable in practice but haven’t been due to some blocker. We might find some things we can work on to improve the situation.

> [@How much effort does backwards compatibility require from library authors?](https://discourse.haskell.org/t/how-much-effort-does-backwards-compatibility-require-from-library-authors/11584/59?page=4):
>
> The thing is that my estimate above (1 hour per package per GHC major release) is foremost an administrative cost, which is to be paid even if there was no breakage at all. Here is a typical workflow: git clone a package. Build it with a new GHC, figure out any allow-newer and source-repository-package necessary. Test with a new GHC, especially doctest. Fix any discrepancies, hopefully minor. Benchmark with a new GHC, compare against old GHC. Fix any new GHC warnings. Fix any cabal check war…

Alternatively, we might be able to take the low-tech solution of finding more volunteers to help.

---

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [May 24, 2025, 2:03pm UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/18 "2025-05-24T14:03:52Z")

</div>

> [@tomjaguarpaw](#):
>
> I think it would be helpful to understand which parts of the post-release workflow explained in a previous discussion of this topic are not amenable to automation in principle, and which are amenable in practice but haven’t been due to some blocker. We might find some things we can work on to improve the situation.

I’m afraid that’s a far more ambitious enterprise than just reducing release cadence.

And even if we managed to drive some hackage based reverse-dep builder that doesn’t blow up in infrastructure cost, that would still only be semi-automatic, because you definitely don’t want to bump dependency bounds without the maintainers final approval.

---

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [May 24, 2025, 2:11pm UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/19 "2025-05-24T14:11:17Z")

</div>

> [@tomjaguarpaw](#):
>
> […] in a previous discussion of this topic […]

…which one? There are now so many to choose from, including this one:

> **[Annual release cycle, its structure and long-term-support. (#18222) · Issues...](https://gitlab.haskell.org/ghc/ghc/-/issues/18222)**
>
> I think this should be once discussed as a GHC proposal. OTOH, the previous time schedule was changed it wasn't discussed as GHC proposal. Therefore I first open...

* * *

> [@hasufell](#):
>
> […] infrastructure cost […]

Remember:

> [@Haskell Foundation Q1 2025 Update](https://discourse.haskell.org/t/haskell-foundation-q1-2025-update/11835):
>
> 2024 Context Financial Outlook The end of 2024 was a challenging time for Open Source generally and the Haskell Foundation was no exception. Open Source foundations struggled to raise funds in the high interest-rate economic environment. LWN has a detailed article about some of the financial troubles faced by OS ecosystems [here](https://lwn.net/Articles/993665/). The Haskell Foundation is not immune to these financial headwinds, but it is much smaller which is a strength in this particular instance. The end of 2024 was a time of…

…funding has been reduced (hence **chreekat** ’s loss of full-time employment).

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [May 24, 2025, 2:20pm UTC](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158/20 "2025-05-24T14:20:26Z")

</div>

I have no doubt that the people at the sharp end of dealing with releases, @hasufell, @bodigrim etc. are experiencing real problems that cause them real work. I’m not involved in that work, so I don’t have a clear idea what it entails, so what I say on this matter is not tailored to the precise reality of the situation.

However, I cannot believe that a quarter of the way into the 21st century, using the world’s most advanced language in common usage, that there isn’t a way of automating the release process that would cut the manual work dramatically, and allow us to comfortably do two releases a year.

Disclaimers:

I am not saying that people like @hasufell, @bodigrim etc. who are already burdened with this work should take on _more_ work.

I am aware that CI and release management is big business in any firm with a software team, so I am not expecting my suggestion to be easy or cheap to implement.

[Next page](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158.md?page=2)