# A tick-tock release cycle for GHC

**URL:** <https://discourse.haskell.org/t/a-tick-tock-release-cycle-for-ghc/4601>\
**Category:** Links\
**Created:** [May 27, 2022, 5:30pm UTC](https://discourse.haskell.org/t/a-tick-tock-release-cycle-for-ghc/4601 "2022-05-27T17:30:17Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![bgamari](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bgamari/32/3599_2.png) [@bgamari](https://discourse.haskell.org/u/bgamari)\
**Post date:** [May 27, 2022, 5:30pm UTC](https://discourse.haskell.org/t/a-tick-tock-release-cycle-for-ghc/4601/1 "2022-05-27T17:30:17Z")

</div>

Here we propose to formalize a rather long-standing pattern in GHC’s release history, specifying a “bimodal” release cycle and giving concrete support windows for these releases. We hope that the this will provide better guidance to commercial users seeking to migrate between GHC versions and make it easier to plan the GHC release process.

> <https://github.com/haskellfoundation/tech-proposals/pull/34>
>
> Here we propose to formalize a rather long-standing pattern in GHC's release his…tory, specifying a "bimodal" release cycle and giving concrete support windows for these releases.
> 
> \[Rendered view\](https://github.com/bgamari/tech-proposals/blob/ghc-tick-tock/proposals/002-ghc-tick-tock.md)

---

<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 28, 2022, 11:42am UTC](https://discourse.haskell.org/t/a-tick-tock-release-cycle-for-ghc/4601/2 "2022-05-28T11:42:50Z")

</div>

Since I can’t be bothered with setting up yet another _“git-house”_ account - the [suggestion](https://github.com/haskellfoundation/tech-proposals/pull/34#issuecomment-1140226643) by @santiweight:

> Another point to make is that the naming scheme is here is imo quite poor. Intuitively, 9.0 would appear to be a long-term support release since it is [a] major version bump. […]

is quite reasonable:

- ghc-`v`.`0`.`n` (for largest `n`) - the most recent maintenance-only version which provides relative stability;
- ghc-`v`.`k`.`m` (for `k > 0`) - for adding and testing language and other extensions;
- ghc-HEAD - for those wanting to stay at the _“leading/bleeding/cutting edge”_.

However, as [noted](http://discourse.haskell.org/t/the-evolution-of-ghc/4008/95) by @hasufell :

> […] that would boil down to maintaining a stable fork of GHC […] and observe its popularity.

…which raises some other questions:

- are there enough GHC developers available to support both codebases, at least for an initial trial with ghc-9.0?
- If successful, will enough GHC developers be willing to continue being maintainers?

If not, and in the [absence of other options](https://github.com/haskellfoundation/tech-proposals/pull/34#issuecomment-1140224280), then the choice is obvious, _at least for non-breaking changes_. As for those **other** changes, the simplest option is to slow down the release rate as [suggested](https://github.com/haskellfoundation/tech-proposals/pull/34#issuecomment-1140222641) by @Bodigrim, until the breakage has been dealt with.