More predictable (minor) release schedules

More predictable release schedules

Currently our release schedule is primarily determined by these factors:

• Time - Every ~6 Months we plan for another major release
• Demand - GHC Maintainers determine to do minor releases "when they need to"

This ticket is about plans to change the second point.

Advantages of the current approach

The current approach is not without advantages. As I see them these are primarily:

• It can reduce the number of releases by holding off from cutting a new release if there is no good reason to do so.
  • This generally reduces the workload of many people who have to perform work every time a new release is cut.
• The smaller number of releases potentially allows branches to be maintained slightly longer.
  • Eventually the work involved in cutting a minor release is dominated by backporting.
  • This means in practice this is a fairly minor difference.
• It's possible to put out a release somewhat quickly if there is "demand".

Disadvantages of the current approach

I've come to believe the current approach of managing minor releases has quite a few flaws

• People naturally disagree about when a release is necessary. This can make it difficult to find consensus about when to cut a release.
• Releases come on a unpredictable schedule, which makes it harder for downstream users to make decisions around expected point releases. This includes people involved in the release process like core library maintainers.
• A small but non-trivial amount of time is spent on deciding if/when point releases are made.
• It makes it harder for ghc maintainers to answer perfectly reasonable questions like:
  • Will there be another 9.6/9.8/9.10 release?
  • When will support for any given major branch be dropped?
  • When will be the next release for any given branch?
• It makes coordination with core libraries more difficult, as ghc devs might request work from them at any point.

Would a more date based release schedule for point releases be better?

Fixed schedule downsides:

• There might be releases cut that contain very few impactful changes.
  • This could be addressed by skipping releases if there are no meaningful changes contained in the current patch set.
• There might be urgent issues requiring an immediate release, violating the schedule. E.g. security issues
  • Historically when it comes to security issues this has been quite rare. I only remember two such issues which would have required releases in the 9.0 series. So I think we can just make exceptions when that happens.

Fixed schedule advantages

• Work required by downstream will mostly happen on a predictable schedule. The same is true for core library coordination. Hopefully this would make the workload easier to manage even if the amount of work required doesn't necessarily change.
• It will always be obvious when one can expect a new point release.
• It makes it easier to plan when to EOL a branch ahead of time.
• While it removes some influence on the release schedule from ghc devs it should result in a more predictable amount of effort being spent on releases.

The concrete proposal

• I propose we adopt a date based approach to minor releases, with a frequency roughly in line with that of the last ~2 years.
• This proposal does not suggest changes to major version release frequency.
• Instead of deciding point releases "on a whim", minor release dates will be set ahead of time for the full expected lifetime of a branch.
• About a month before a point release the GHC team decides if they want to skip a given release.
  • If they want to skip the release announce the intention to do so.
  • If no reasonable rejection to skipping the release is announced within 3 weeks the release will be skipped.
  • If there are objections the release will happen as planned.

The concrete proposed schedule is this repeating 12-month pattern:

2026-03: Tock-9.22.1 - Initial Release
2026-04: Tick-9.20.3
2026-05: Tock-9.22.2
2026-06: Tock-9.18.5 - Last point release
2026-09: Tick-9.24.1 - Initial Release
2026-10: Tock-9.22.3
2026-11: Tick-9.24.2
2026-12: Tick-9.20.4 - Last point release

Or in a more visual representation:

Key attributes would be:

• Point releases are stretched over 15 Months.
• There is no more than a single release per month planned.
• Minor releases are more frequent after initial release slowing down over time.

---

I think this would be an improvement and I plan to push us towards such a model unless there are good concerns that convince me otherwise. But we should re-evaluate if this worked well after a year or two assuming we end up adopting it.

So please let me know if you think this is a terrible idea!