# 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:** 1\
**Showing post:** 17

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

---

_[View the full topic](https://discourse.haskell.org/t/please-revise-ghc-release-policy/12158)._