Skip to content

Commit 7bbb095

Browse files
committed
Add GHC LTS Releases blog post
1 parent 5cc07e7 commit 7bbb095

File tree

1 file changed

+95
-0
lines changed

1 file changed

+95
-0
lines changed

content/ghc-lts-releases/index.md

Lines changed: 95 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
+++
2+
title = "GHC LTS Releases"
3+
date = 2025-07-07
4+
[taxonomies]
5+
authors = ["Andreas Klebinger"]
6+
categories = ["GHC"]
7+
tags = ["Release"]
8+
+++
9+
10+
# GHC will start maintaining an LTS release/branch in the near future
11+
12+
A release being designated LTS (Long Term Support) in this case means we plan
13+
to support it over a longer timeframe than usual.
14+
15+
Concretely the plan is to provide updates for a LTS releases for *at least* two
16+
years. Most likely we will support LTS releases for even longer than that,
17+
aiming for a support window of three years currently.
18+
19+
During this time we will be providing minor releases fixing bugs as with any
20+
other release. The main difference being that we will do so for a longer period
21+
of time.
22+
23+
There are no plans to backport any new features to LTS releases after their
24+
initial release.
25+
26+
In terms of frequency of LTS releases we plan to have an overlap between LTS
27+
support windows of different LTS series of six months.
28+
29+
A potential timeline might then look like this:
30+
31+
```
32+
2025 Aug - LTS 9.14 released
33+
2028 Spring - LTS 9.22 released
34+
2028 Summer - LTS 9.14.X - last 9.14 point release
35+
2031 Spring - LTS 9.X released
36+
2031 Summer - Last 9.22 point release
37+
38+
```
39+
40+
# Non-LTS releases
41+
42+
GHC will continue to release new major non-lts releases on a ~6 Month cadence.
43+
We expect to cut back on the lifetime of these releases slightly, dedicating
44+
the resources freed up this way to enable a longer support window for the LTS
45+
releases.
46+
47+
# Why LTS releases?
48+
49+
In practice some releases always saw more adoption than others by users. The
50+
GHC Team has not been blind to this fact and has at times informally extended
51+
the life of a certain release based on this as well.
52+
53+
This resulted in a sort of informal "post-hoc LTS" status of releases. At times
54+
with support windows not much shorter than our proposed minimum of two years.
55+
56+
This worked reasonable well for people who were confident to stay on a fairly
57+
old release, only upgrading to a newer "post-hoc LTS" once the dust settled. It
58+
also worked out for those who picked one of those "post-hoc LTS" releases by
59+
happenstance before it was clear the release would end up as "post-hoc LTS".
60+
61+
However users who adopted major releases which did not end up as "post-hoc LTS"
62+
often had to choose between upgrading earlier than expected, or risk running
63+
into a show stopping bug after the support window of the release had already
64+
ended. Similarly much of this was based on informal community sentiment and
65+
rarely written down explicitly. Making this information hard to access for
66+
members not deeply involved in the day to day of the haskell community.
67+
68+
By designating a major release as LTS ahead of time we hope that users can make
69+
a informed decision about which GHC version they pick. Making it clear what the
70+
tradeoffs will be. With a clear choice between a longer support window or the
71+
newest features.
72+
73+
# Why not make post-hoc LTS releases official instead?
74+
75+
This is a question that has come up a lot in discussion. The major downsides of
76+
this are a lack of predictability, and that a lot of time might be lost between
77+
the initial release and any such decision. If we declare a release as LTS 9
78+
months after its .1 release we essentially shaved off months from the LTS
79+
support window.
80+
81+
On the flip side if we announce it ahead of time everyone knows that a given
82+
release will be the new LTS. So the hope is that this encourages more and
83+
quicker support for the release by the community. Hopefully compressing the
84+
timeline of bug fixing, testing and eventual widespread adoption.
85+
86+
Overall I'm hopeful that LTS releases being explicit will remove a lot of
87+
ambiguity around GHC versions. And while the guaranteed LTS support window
88+
might not be as long as one might hope having LTS releases with longer
89+
guaranteed support window should still be helpful to people working on long
90+
running haskell projects.
91+
92+
# Next steps
93+
94+
The first LTS release will be GHC 9.14, which will be released this summer!
95+

0 commit comments

Comments
 (0)