GHC version support policy

Haskell Foundation
#1

Greetings, forum. A little announce here, if I may.

I’d spent a lot more time than I’m willing to admit on locating the info table “which version is currently EOL / not EOL” for GHC. You know, pages like these, that many big projects keep:

Regardless of the frequency how often one needs this information (which may range from “daily” to “never” depending on role) — when it’s needed, it better be reachable at fingertips distance.

Enter :point_right: Glasgow Haskell Compiler (GHC) | endoflife.date :point_left:

The site endoflife.date is a non-authoritative community resource, it aggregates just this sort of lifecycle information over hundreds of software projects.

There’s a GHC page now on it, too. :confetti_ball:

It just landed today, and the pilot version is so far static. LMKWYT. The aggregator, however, does support automatic updates, and I’ll be applying further effort to get the GHC page seamlessly autoupdating too.

Huge thanks to GHC Release Managers for maintaining the source information this is based upon. Without the GHC status table this thing wouldn’t be possible.

14 Likes
#2

I can see this to be a useful reference, thanks for your effort! What is the criteria for “recommended for use”? Say, if it includes tooling support, I would be hesitant to recommend GHC 9.2 as it is considered deprecated by HLS per its GHC version deprecation policy.

As an aside, the release notes link for GHC 9.2 is broken as it doesn’t seem to conform to the usual URL schema, maybe that’s something for haskell.org to fix though.

#3

I believe these days the decision in HLS about which GHC version to support are less about holistic ecosystem considerations, but about maintenance burden.

Users of older GHCs can, after all, still use older HLS.

So I wouldn’t read too much into it.

4 Likes
#4

That’s a great idea! I don’t care about the EOL status so much but about release dates and latest minor releases in each line. During Cabal maintenance I often find myself struggling to find these dates and minor versions.

I wish there was a more familiar URL, e.g. one under haskell.org. Maybe whoever is in charge of the domain could look into adding a redirect?

2 Likes
#5

Speaking of HLS! @ozkutuk I did pursue an intention to add HLS on a separate page. However…

The closest to a support policy that I found for HLS was this table. I understand the necessarily tight coupling of HLS to GHC — but the table is prominently keyed by versions of GHC, not by versions of HLS.

Turns out, that’s intensely confusing. Versions 2.6.0.0, 2.5.0.0, 2.2.0.0 appear in multiple rows. Version 2.5.0.0 is simultaneously in rows with full support and deprecated.

Imagine trying to write a script, which from that data, produces a table somewhat like so:

image
image767×1320 123 KB

I figure, that’d be pretty hard and error-prone.

I couldn’t convince endoflife.date maintainer to merge in the above. He asked me to ask HLS team to clarify the policy. It just doesn’t look like a support policy of HLS versions — but rather, a support policy of GHC versions, by HLS.

What is the criteria for “recommended for use”?

That a good question, but I must defer it to GHC Release Managers. Its what the source table says :man_shrugging: As a secondary source, I’m interpreting every row without “not recommended for use” as “recommended for use”, hopefully that’s not a stretch.

Perhaps GHC wiki should update 9.2 to read “not recommended for use”.

1 Like
#6

It just doesn’t look like a support policy of HLS versions — but rather, a support policy of GHC versions, by HLS.

That’s right. Our primary concern is “which versions of GHC do we support?”. We don’t do patch releases for old major versions of HLS itself (there’s no real reason to be on anything except the latest version that support your GHC), so there isn’t really a sensible concept of “supported HLS versions”. In particular I don’t think your proposed table is right: there is no sense in which HLS 2.4 is “actively supported”. We’re never going to release a new point release of 2.4, there’s no point.

You should think of HLS more like vim than like GHC.

3 Likes
#7

Great @michaelpj, that’s useful to know, thanks. Saves me the effort in vain of trying to add a similar table for HLS :slight_smile:

#8

I don’t think it’s a bug, I think it was on purpose. You just have to insert /html, like this: 2.8. Version 9.2.8 — Glasgow Haskell Compiler 9.2.8 User's Guide