Skip to content

Add GHC LTS Releases blog post #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 15, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 95 additions & 0 deletions content/ghc-lts-releases/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
+++
title = "GHC LTS Releases"
date = 2025-07-07
[taxonomies]
authors = ["Andreas Klebinger"]
categories = ["GHC"]
tags = ["Release"]
+++

# GHC will start maintaining an LTS release/branch in the near future

A release being designated LTS (Long Term Support) in this case means we plan
to support it over a longer timeframe than usual.

Concretely the plan is to provide updates for a LTS releases for *at least* two
years. Most likely we will support LTS releases for even longer than that,
aiming for a support window of three years currently.

During this time we will be providing minor releases fixing bugs as with any
other release. The main difference being that we will do so for a longer period
of time.

There are no plans to backport any new features to LTS releases after their
initial release.

In terms of frequency of LTS releases we plan to have an overlap between LTS
support windows of different LTS series of six months.

A potential timeline might then look like this:

```
2025 Aug - LTS 9.14 released
2028 Spring - LTS 9.22 released
2028 Summer - LTS 9.14.X - last 9.14 point release
2031 Spring - LTS 9.X released
2031 Summer - Last 9.22 point release
```

# Non-LTS releases

GHC will continue to release new major non-lts releases on a ~6 Month cadence.
We expect to cut back on the lifetime of these releases slightly, dedicating
the resources freed up this way to enable a longer support window for the LTS
releases.

# Why LTS releases?

In practice some releases always saw more adoption than others by users. The
GHC Team has not been blind to this fact and has at times informally extended
the life of a certain release based on this as well.

This resulted in a sort of informal "post-hoc LTS" status of releases. At times
with support windows not much shorter than our proposed minimum of two years.

This worked reasonable well for people who were confident to stay on a fairly
old release, only upgrading to a newer "post-hoc LTS" once the dust settled. It
also worked out for those who picked one of those "post-hoc LTS" releases by
happenstance before it was clear the release would end up as "post-hoc LTS".

However users who adopted major releases which did not end up as "post-hoc LTS"
often had to choose between upgrading earlier than expected, or risk running
into a show stopping bug after the support window of the release had already
ended. Similarly much of this was based on informal community sentiment and
rarely written down explicitly. Making this information hard to access for
members not deeply involved in the day to day of the haskell community.

By designating a major release as LTS ahead of time we hope that users can make
a informed decision about which GHC version they pick. Making it clear what the
tradeoffs will be. With a clear choice between a longer support window or the
newest features.

# Why not make post-hoc LTS releases official instead?

This is a question that has come up a lot in discussion. The major downsides of
this are a lack of predictability, and that a lot of time might be lost between
the initial release and any such decision. If we declare a release as LTS 9
months after its .1 release we essentially shaved off months from the LTS
support window.

On the flip side if we announce it ahead of time everyone knows that a given
release will be the new LTS. So the hope is that this encourages more and
quicker support for the release by the community. Hopefully compressing the
timeline of bug fixing, testing and eventual widespread adoption.

Overall I'm hopeful that LTS releases being explicit will remove a lot of
ambiguity around GHC versions. And while the guaranteed LTS support window
might not be as long as one might hope having LTS releases with longer
guaranteed support window should still be helpful to people working on long
running haskell projects.

# Next steps

The first LTS release will be GHC 9.14, which will be released this summer!