[new product] GHC (Glasgow Haskell Compiler)

[ulidtko]

GHC and HLS are two open-source projects.

I'm using endoflife.date a lot, and missing those two in there 🚀

[ulidtko]

Tested on local jekyll; and the netlify preview looks the same 🎉

[captn3m0]

Do you mind splitting this into two PRs? I am wary about adding HLS, which doesn't seem to have a support policy of its own - only a "GHC Version Support" policy.

I've read through this several times, and I'm still unsure if we can call anything except for HLS2.9 "actively supported".

[ulidtko]

Thanks for review @captn3m0 🙏

I've shelved off the second commit (that used to add HLS) — the PR is only GHC now.

And you're exactly right sir, in case of HLS it's a hassle to figure out; that's what motivated me to add it in the first place... It's very tightly coupled to GHC (so that IDE's don't have to be), and there isn't a clearly spelled out support policy, at least yet.

It we get the GHC table landed on site — it'll enable me to approach the HLS team, and hopefully work out a clarification on the "what HLS supported how" question. Because there'll be a nice example to demonstrate, one they could relate to.

Please approve & merge.

[captn3m0]

A few minor suggestions, which should be easy to incorporate. I would like to find better terminology and explanation for what support means before we merge.

"Further releases planned" and "Recommended for use" are very vague terms. If a bug is found in 9.4 today (with no releases planned), what is the user expectation? Can we call 9.4 supported if it is recommended for use, with no promise of support?

Also, would be nice to have a bit in the text about the versioning methodology (even=stable?) and the release cadence.

[ulidtko]

Hi again @captn3m0, thanks for review. Most comments addressed.

On second dive, I found another page on the wiki with some actual release policies. Got some nuggets from there. The verbal section markdown was rewritten, still short but elaborated better now.

(BTW, not keen on keeping the direct link to here; there's audience mismatch, as the wiki is directed at GHC devs & release managers, not users. But LMK your judgement whether to remove the link)

---

"Further releases planned" and "Recommended for use" are very vague terms.

Tough one; I struggle to improve on this wording. See in comments...

If a bug is found in 9.4 today (with no releases planned), what is the user expectation?

If the bug is severe enough, and there somehow appears a patch fixing it on 9.4 (!) — then a new minor release will become planned, per my understanding. IIUC that's exactly what happened with 9.4.7 — it's a single-fix patch release; whilst most others batch up dozens to hundreds fixes.

Of course, this is all conditional on 9.4 not being EOL / "not recommended for use". Then expectation is different.

Can we call 9.4 supported if it is recommended for use, with no promise of support?

See my comment, hopefully answered there... I guess "promise of support" is vague enough that the GHC table avoids that wording altogether.

Also, please help with suggestions here. The only idea I get is renaming "Recommended for use" → "Not EOL"... but the resulting in-table double-negations read awkward to me.

Also, would be nice to have a bit in the text about the versioning methodology (even=stable?) and the release cadence.

Both done.

[captn3m0]

We can also maintain a custom column for "Usage Recommendation", that can track the upstream suggestion. I'm very hesitant of setting eol: false for a release that upstream calls "🟡 Stable but no further releases planned".

With this in place, we will have something like:

Release	Active Support	EOL	Usage Recommendation
9.12	Yes	No	Yes
9.10,9.6	No	No	Yes
9.8,9.4,9.2	No	Yes	Yes
9.0,8.10	No	Yes	No

All it would take is for GHC to clearly define what "Stable" means. Just adding a simple wording like: "Stable series with no planned releases can still receive emergency/critical fixes." would be helpful.

Or can we look at the history of GHC releases to see if there has ever been a Yellow series that got an unplanned release for an important bugfix?

[ulidtko]

Yes, I gave that exact example :)

what happened with 9.4.7 — it's a single-fix patch release; whilst most others batch up dozens to hundreds fixes

hard to imagine if that was "planned"...

[ulidtko]

@captn3m0 so in my eyes, "Active support" == "Usage recommendation", and these 2 columns would be always identical.

e.g. for 9.10 it's incorrect to say "Active support: no" — as there's version 9.10.2 in-the-works right now (I'm hoping my patch from April will appear in it). straightforwardly, this includes a notion of "active support" in the form of reviewing, merging & backporting patches

[ulidtko]

BTW, I'd just run the netlify preview by the actual release managers (off GitHub) asking for a proof-read / review — and got a "looks good" from one. No egregious mistakes so far.

[captn3m0]

Thanks. I was trying to capture the difference between "🔵 Current major series", and "
🟢 Stable" - but doesn't look like there's much…

The text looks pretty good, and I'm gonna go ahead and merge. The one enhancement we should consider over time is switching from Yes/No to real dates, so as to provide a better understanding.

[captn3m0]

LGTM.

[welcome]

Thank you and congratulations for your first contribution! endoflife.date is a community wiki, and we're always looking for more contributions 🥇 💯 🎉.

[ulidtko]

Awesome, thanks! 🙏

I'm thinking of a custom script to auto-update release-data from that wiki table. (git tags convey only the dates)

And HLS also, some day.

Meanwhile, @captn3m0 could you also approve #6286 ? It only fixes product-schema.json, touches nothing else.