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).

[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.

[Bodigrim]

For at least five years since what? Shipped with which GHC? I assume the meaning is "at each given moment of time the Cabal library at HEAD should be buildable by all GHC versions, released in the past 5 years, against corresponding sets of GHC boot libraries", but it has to be spelled out.

[Mikolaj]

I think Bodigrim's is not a bad paraphrase and it uses cabal maintainer's POV, which is more natural. The original text uses the POV of a GHC user, but that property follows from the other.

[ffaf1]

I have reworded the bullet points, if they are not clear I welcome suggestions.

[Bodigrim]

Let's just say "should be able to drive", because "work with" does not have any precise meaning.

[ulysses4ever]

I'd be fine with this chance personally, but I don't think this serves less experienced users as well: I can imagine people that would be confused by "drive". That's why I sugested putting both above. But that's not a big population of people who could be confused, perhaps, so I'm not actively against this proposal either.

[ffaf1]

I was one of those users. Given that https://en.wikipedia.org/wiki/Compiler does not mention “driving”, I am partial to writing it longhand too (I am open to suggestions).

[geekosaur]

Document "drive": that cabal-install will work with the Cabal library (usually but not always the one that came with the ghc version) used to build the package.

[ffaf1]

Good suggestion, I updated the description.

[Bodigrim]

I don't understand what it means. As it stands, it suggests that we want to perpetuate each and every compatibility shim accumulated in the codebase, even for obsolete versions of GHC. If that's not the meaning, I suggest to remove the sentence entirely.

[ffaf1]

We don't remove old GHCs as soon as they go out of the five-year window. We usually remove them when support gets painful.

I am not against removing this, but it would be substantive policy change versus a clarification.

[Mikolaj]

Yes, we do perpetuate potentially forever. The "best effort" policy is more precisely a "minimal effort" policy, namely, if any substantial effort is needed to maintain the compatibility, by us or by any member of the ecosystem, we drop the GHC. Surprisingly often (or we lack feedback), no effort is needed to go quite a way longer than the 5 years and it's valuable, even just to have more data from old GHCs when something breaks or when we finally need to drop some of the GHCs (outside the window or not) and we want to understand how universally critical our reasons are.

[ffaf1]

I replaced "best-effort" with "minimal-effort".

[Bodigrim]

Is this a promise that if my PR passes CI then it satisfies the GHC support window policy? So effectively a developer should only care to pass CI checks, and it's maintainers who are responsible to maintain CI in line with the GHC support window policy?

[Mikolaj]

I think so. That's what makes it sensible. Am I right?

[ffaf1]

Not a promise, but a useful bit for contributors (maintainers try to translate all this into CI).

Sadly some changes (see #11510) cannot be caught in CI.

[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).

[Bodigrim]

Huh? Now I don't follow. Who is "the Cabal library used to build the package" and who is "the package"?

cabal-install has to drive either GHC itself (as in "pass all necessary options to ghc --make with graceful degradation for older GHCs", for build-type: Simple) or drive Setup executable (for build-type: Custom", and in this case Setup is built always using the same Cabal-the-library that came with the GHC version). In both cases it interfaces through CLI and never interacts with an older Cabal-the-library as a library via its API.

[geekosaur]

I think we've had at least one case of someone using setup-depends to (try to?) change the Cabal used by a custom Setup?

[Bodigrim]

Hmm, now I recall something, perhaps you are right.