Clarify GHC support window

[ffaf1]

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• N/A [] Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

Close #11608

[geekosaur]

FTR, #7209 (comment)
@Bodigrim, does this address your question?

[Bodigrim]

Thank you, it does.

Can I open a larger can of worms and ask for rationale behind the policy?

• I don't think that prescribing absolute terms in astronomical years makes much sense per se. I assume the rationale behind them is something like "cabal-install from the last non-EOL'd Ubuntu LTS (Debian stable, Fedora, whatever is your benchmark) should be able to complete cabal install cabal-install". If that's the case, could the policy be expressed in such terms? I think it's more actionable than simply counting days.

• I don't understand why the rules for Cabal-the-library are so strict, what's the rationale behind them? If I'm restricted to GHC boot ("out-of-the-box") libraries then certainly I'm also restricted to the corresponding Cabal-the-library and will not attempt building a new one. If I'm not restricted to GHC boot libraries and so can build a new Cabal-the-library then why would it matter that it needs newer dependencies?

[ffaf1]

Let me ping @Mikolaj and @ulysses4ever .

I believe this is the right place to codify what is shared knowledge, but of course ideas on how to make the policy better are welcome.

[ulysses4ever]

Yes, give me this weekend to comment. I have opinions!..

[ffaf1]

Sure, we are in no rush!

[ulysses4ever]

I don't think that prescribing absolute terms in astronomical years

This is my first and biggest consern: it's excruciatingly painful to compute the latest major version of GHC that we support, and we have to do it on a weekly basis in my experience. I think much nicer would be to express backward compat in terms of number of major GHC releases (optionally, we could use the notion of GHC LTS).

Whether 5 years (worth of GHC releases) is too aggressive or not for the library: I don't have an opinion. I think it's not bad. There's also something I don't understand here:

I don't understand why the rules for Cabal-the-library are so strict, what's the rationale behind them? If I'm restricted to GHC boot ("out-of-the-box") libraries then certainly I'm also restricted to the corresponding Cabal-the-library and will not attempt building a new one. If I'm not restricted to GHC boot libraries and so can build a new Cabal-the-library then why would it matter that it needs newer dependencies?

Why are you concerned about boot libraries but not the actual matter of the support window: the ability to build newer Cabal with older GHCs? Imagine someone is stuck with old GHC but wants to build a package that uses relatively new cabal spec. If we don't support building newer Cabal with that old GHC, they will be stuck completely. I'm sure I'm missing something in your reasoning...

---

The second concern I have about our spec for the support window is that we don't specify guarantees that cabal-install gives about driving GHC rather than compiling with GHC. I think we should add something about it. As a starter, 5 years would be fine, perhaps. Maybe 7, to show that out drive-compat is better than our build-compat.

Recently, Oleg mentioned another interesting way to define the window, particularly for driving (which should be the most conservative): support all GHCs that are "easily available", e.g., through GHCup. Although I dislike how informal it is, I think it's an interesting direction of thought, and I'm curious what others think about it. I do tend to think that, formalities apart, it's a good idea to strive for the ability to drive extending as far as the oldest GHCs that are available, say, from GHCup.

[Mikolaj]

IMHO, years vs GHC releases decouples us from the GHC release cadence changes, which is good. "Last 3 GHC LTS releases" would be better than "last 5 major releases" if you are strongly in favour of ditching the old method.

Re length of the window, I hope it's clear we are open to exceptions. Given that, I'd keep the long window rather than shorten it, so that we get more signal by processing the exception requests. So far, I think the window does not cause too much pain. Unless people just suffer in silence, but if so, that's a bigger social problem. Maybe, while we are amending the text, it would make sense to clearly state that if users or developers make a convincing case for a breaking change, any of the windows can be shortened by the maintainers, with suitable announcements given in release changelogs (for the benefit of users and developers that, in turn, depend on the windows).

[Bodigrim]

Can I open a larger can of worms and ask for rationale behind the policy?

OK, it's clear from the discussion above that there are no commonly recognized principles behind the policy and it simply codifies a historical tradition. That's fine (I mean it), we can discuss whether there is interest to develop such underlying principles separately.

Re length of the window, I hope it's clear we are open to exceptions.

If that's the case, I'd expect the policy to define exactly what makes a convincing case for an exception. Otherwise you are just encouraging people to be loud enough and annoying enough to push whatever they want.

[ulysses4ever]

IMHO, years vs GHC releases decouples us from the GHC release cadence changes, which is good

I don't get it. Could you perhaps describe a particular scenario when it can bite us?

Here's maybe an example. Take GHC 8.10. There has been many major releases since 810, but it was so solid that it can still be relevant. In this case the astronomic time may serve the goal of supporting a good old release better. In contrast, think of an old bad release (9.0 for instance) we'd like to stop supporting it earlier rather than later, perhaps. For that goal, the release-based measure probably works better (provided release stream is steady) because new releases will hopefully follow earlier than usual.

Ultimately, my main argument for the new method would be: The whole ecosystem moves in concert with GHC releases, so thinking in (major) releases rather than years makes a lot more sense to me. That's on top of the utter inconvenience of the current approach.

[ffaf1]

I don't get it. Could you perhaps describe a particular scenario when it can bite us?

If GHC devs decide to pull a Firefox and release frequently, “last three major releases” could mean something quite different from what it means now. Years and months are not coupled to such decisions.

Of course the change would not get unnoticed by cabal maintainers, and we could update the relevant policy.

[ulysses4ever]

Ah, I see, thank you, @ffaf1. Yeah, the utter inconvenience of the current method still pushes me in the camp let's worry about the bad thing only whne/if it arises...

[Mikolaj]

OK, it's clear from the discussion above that there are no commonly recognized principles behind the policy and it simply codifies a historical tradition.

That's correct.

Re length of the window, I hope it's clear we are open to exceptions.

If that's the case, I'd expect the policy to define exactly what makes a convincing case for an exception. Otherwise you are just encouraging people to be loud enough and annoying enough to push whatever they want.

I wouldn't mind people being loud about cabal and certainly I'd encourage communication about their needs. So far, with this particular rule, we lack feedback, not complain about noise. This is what I meant by "signal" when I said a longer window makes it more likely we get one.

[Mikolaj]

IMHO, years vs GHC releases decouples us from the GHC release cadence changes, which is good

I don't get it. Could you perhaps describe a particular scenario when it can bite us?

Sure. E.g., we declare we support 10 last major releases (== 5 years of half-year releases) and tomorrow GHC HQ decides to make releases take 1 year (or 1 quarter).

[philderbeast]

Could you please open an issue for this?

I've seen a couple of comments about GHCJS support not being maintained and would like to see an issue for that too so that we're explicit about its support window.

The default branch, the ghc-8.10 branch, of the GHCJS fork was last updated Sep 25, 2022.

[geekosaur]

Could you please open an issue for this?

Sorry, who is this aimed at?

[ulysses4ever]

we never had formal guarantees for suporting ghcjs, and I don't think this should change as it's a dying technology

[philderbeast]

Could you please open an issue for this?

Sorry, who is this aimed at?

@ffaf1 as the PR author.

A pull request fixes a problem that is described in an issue. Make sure to file an issue before opening a pull request.

-- CONTRIBUTING.md Pull Requests & Issues

I was asking for a GHC support window issue first so that I could follow up with one about GHCJS.

[ffaf1]

Could you please open an issue for this?

Done!

If we do not agree on specifics, we can merge what has consensus and leave the rest for another PR.

[ulysses4ever]

Yes, this has been dragging for too long. It doesn't look like the switch from years to major releases in the definition of support window collected enough support. So I'm fine with merging it with years.

Another issue I was thinking of is that Contributing.md isn't very discoverable. I think some of these windows (the ability to drive, at least) would be interesting for general public. So maybe we should find a way to refer to this section of contributor's guide from some place more visible, e. g. Readme? Moving it to readme altogether would seem even nicer to me but I think people had reservations about that in the past.

[geekosaur]

Maybe we need a SUPPORT.md? CONTRIBUTING.md seems like the wrong place for it to me anyway.

[ulysses4ever]

CONTRIBUTING.md seems like the wrong place for it to me anyway.

same. I think @Mikolaj suggested to put it there.

Maybe we need a SUPPORT.md?

What do other people do? It'd be good to not invent new approaches...

[geekosaur]

To be honest, none of the things I have checked out have it anywhere, including various build tools and such which would be most likely to have it. I think it's usually on a web page or a support/documentation wiki.

[Bodigrim]

So maybe we should find a way to refer to this section of contributor's guide from some place more visible, e. g. Readme? Moving it to readme altogether would seem even nicer to me but I think people had reservations about that in the past.

I'm very much in favor of README.md, please.

[ffaf1]

What do other people do? It'd be good to not invent new approaches...

GHC has it in their wiki.
HLS has it in readthedocs.
Stack has it in CONTRIBUTING.md.

[ffaf1]

I moved support-window bits to README.md, closing outated comments.

If the wording is clear and the position is correct, we can merge this as a description of what we do now, and then open a new ticket to quarrel on what we really should be doing.

[geekosaur]

Minor stuff.