RFC: Dropping build support for GHC < 8

[emilypi]

Hi Everyone,

This project currently supports GHC >=7. However, as of the latest Haskell Survey, roughly 1% of the community is using a GHC < 8.0:

However, looking at CI times, on average, we spend roughly 47% of CI time on GHC < 8.0. This means that we're spending close to half of all build time supporting 1% of the community for a niche case that disproportionately negatively affects the 99%. Dropping GHCs would significantly improve the contributor pipeline, and help ease the burden going forward for both users and maintainers. Part of me suspects that we support old GHCs in order to not cast anyone into the lurch if they happen to not be able to upgrade. However, I think having a concrete stability policy is just as good, and will set expectations appropriately so that people know what's coming and can act accordingly. So, my proposal is this:

1. We drop GHC < 8.0 for Cabal and cabal-install. Older GHC users can always use older versions of Cabal. The point to stress here is that we want to put cap ongoing support at roughly 5 years for a particular GHC.
2. We establish a concrete stability policy to this effect, and announce it far and wide.
3. etc. (whatever we come up with here as refinements)

[chris-martin]

I do maintain libraries that support versions of GHC older than the GHCs I "use" myself, so I'm wondering if 1% is perhaps an underestimation of who this might affect in some way. (That said, I don't think I actually still support GHC 7.x on anything, because 8.0 added Semigroup.)

One nicety that might make this entirely painless for some "niche case" users: Could the default Cabal version in the setup GitHub action be "the latest Cabal version that supports the requested GHC version"? That might spare some people the extra brain space of mapping GHC versions to appropriate Cabal versions themselves.

[Bodigrim]

@chris-martin there are two types of Cabal-GHC compatibility at play. One is which GHC is needed to build Cabal from the sources, and I assume the ticket is about this (is it?). Another one is which GHC bindists are supported by Cabal in runtime (this is what matters for consumers such as GitHub actions).

[chris-martin]

Ah. In that case I don't even understand how it would be possible to be affected by this.

[emilypi]

Ah. In that case I don't even understand how it would be possible to be affected by this.

I've heard-say that some people are running GHC 7.2 still in production and want progressive fixes for it 😁. This would obviously put those people out, but the burden is too great for this team.

[mightybyte]

Off the top of my head I can't think of a compelling argument for why Cabal should continue supporting GHC < 8. If there is anyone using GHC < 8 in production, I think it's perfectly reasonable that they should also be able to pin to an older Cabal release as well.

[eborden]

Yes please, drop support.

[jneira]

The unique project i maintained requiring ghc-7.10.3 was eta-lang:

https://github.com/typelead/eta/blob/97ee2251bbc52294efbf60fa4342ce6f52c0d25c/stack.yaml#L1

and its fork of cabal, etlas

https://github.com/typelead/etlas/blob/bbd7c558169e1fda086e759e1a6f8c8ca2807583/stack.yaml#L37

But being them both hard forks, they did not depend on cabal in any way afaik
Well i was buillding them with cabal too but the project is in indefinite hibernation so 🤷

Sad to have to speak about it in past tense 😞
(i think that target the jvm still makes totally sense for haskell)

[Kleidukos]

I second this proposal, the engineering burden for a nigh-defunct compiler version is too high. This will also help us refine our general backward compatibility requirements.

[jneira]

An arguments to keep at least 7.10.3 would be it is still supported in haskell actions and ghcup and from a quick search
There are several projects mentioning it in github: https://github.com/search?p=4&q=ghc+7.10.3+extension%3Ayml+extension%3Ayaml&type=Code
including amazonka
In hackage there tons of packages claiming they support ghc-7.10.3 (or lower): https://hackage-search.serokell.io/?q=%28GHC%7Cghc%29.*%3D%3D.*7%5C.10%5C.3

So maybe a little bit more conservative option could be keep only 7.10.3, as 7.10.* would be in theory easy to port on and we will give users a window time to migrate their code.
I hope dropping the rest of ghc versions will still save us quite ci time.

[merijn]

@jneira
As I (after careful rereading) understand the proposal the issue is about dropping support for building cabal itself with GHC <8. Cabal and cabal-install would still support using (i.e., building other packages) with older GHCs, so unless you see a compelling reason why people using GHC 7.10.3 cannot use a Cabal build with GHC >8, I think your concerns are mostly unrelated to the proposal?

I'm a solid +1 on dropping support for building cabal with GHC < 8, if my above summary is correct. :)

[chris-martin]

Is there an automated way to search Hackage for projects that have both

1. a dependency on the Cabal package; and
2. a lower bound on base that is lower than 4.9?

[jneira]

cabal-install would still support using (i.e., building other packages) with older GHCs

Aha, thanks for the clarification i missed your first comment about. In that case i would be fine too.