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.

[emilypi]

I think +61 upvotes and not a single response to the contrary is a good indicator that this will go through. Thanks for getting the feedback to us so quickly 😄

[Ericson2314]

I'm not too worried about CI time since each compiler is tested in parallel. However Cabal/cabal-install currently contains way to much code. We absolutely do need to find ways to delete as much of it as possible and this can help with that.

[cartazio]

I agree with nuance as articulated by @merijn

[Kleidukos]

@cartazio Cabal's support for GHC < 8 for projects is a different issue, we're talking here about cleaning-up the codebase of Cabal itself to remove CPP statements so that this codebase can be freed of old compilers.

[cartazio]

Yup that’s what I throughly Merijn was clarifying

[drathier]

How about dropping support when usage stayed below 5% for a year? Something like that would give a heads up to people next time.

[jneira]

• a dependency on the Cabal package; and

• a lower bound on base that is lower than 4.9?

I still think it would be great to do that query, to know for sure what packages will be impacted
EDIT: Not sure if the regexp is correct but https://hackage-search.serokell.io/?q=%5E%5Cs*base%5Cs*%28%5B%5C%5E%3D%3C%5D.*4%5C.%5B0-9%5D%7C%3C.*4%5C.10%29

[fgaz]

@jneira I think it'd be useful to compare that with the packages that are already unbuildable and see how much that number would increase

[isovector]

How about dropping support when usage stayed below 5% for a year? Something like that would give a heads up to people next time.

Rather than this, it makes more sense to have something like an LTS model. Explicitly state that (all|only some) versions will be supported for $LENGTH. Letting user behavior dictate this is just asking for trouble.

[eborden]

Completely agree @isovector. A version policy that includes sunset dates allows an explicit contract that users can plan around.

[merijn]

@isovector There is already an LTS model, and it is (per phadej's comment) that building Cabal is supported by any GHC of the past 5 years and cabal-install with any GHC of the past 3.

Edit: Heh, now I can't find where I read his comment.

[Kleidukos]

For comparison, here is the result from this year's survey:

[jneira]

master cabal-install is not longer buildable with ghc < 8.2 since a54f9d2 , not sure if that was on purpose as it exceeded the limit proposed here. hackage 3.6.2.0 is not buildable for ghc < 7.10
Cabal still is buildable with older ghcs but after #8064 it won't for ghc < 7.10

[jneira]

Not sure what is the protocol to follow with RFCs, but we are taking steps towards this so i would say #8079 would close this as rfc accepted and implemented

[jneira]

Also there is a note in the readme stating the window support for ghc versions used to build cabal and cabalinstall:
https://github.com/haskell/cabal/blob/master/CONTRIBUTING.md#conventions

[phadej]

I'm looking at this, and Cabal-syntax.cabal still says base >= 4.6 && < 5, in master?

For me this issue doesn't seem to be solved, at least properly.

[Mikolaj]

Agreed. PR welcome. See also #8715

[phadej]

I won't make a PR. I hope that uploaders of Cabal/-syntax will fix these before uploading packages to Hackage.

[ulysses4ever]

It looks like, the current lower bound base >= 4.9 still not up to date: it allows GHC 8.0 while we dropped it recently, so it should be 4.10.

[philderbeast]

I'd be willing to have a go at cutting a PR for this. It looks like we'll need to bump to base>=4.13 or even base>=4.14¹ because of the time>=1.12 constraint in cabal.project. That equates to ghc>=8.8 or ghc>=8.10.

cabal/cabal.project

Line 28 in 054108f

constraints: time >= 1.12

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5
$ cabal build all --enable-tests --enable-benchmarks
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: Cabal-3.11.0.0 (user goal)
[__1] next goal: time (dependency of Cabal)
[__1] rejecting: time-1.8.0.2/installed-1.8.0.2
  (constraint from project config /.../cabal.project requires >=1.12)
[__1] trying: time-1.12.2
[__2] next goal: base (dependency of Cabal)
[__2] rejecting: base-4.12.0.0/installed-4.12.0.0 (conflict: time => base>=4.14 && <5)

Footnotes

1. It looks like the solver is picking the last in the 1.12.* series from hackage; time-1.12.2 requires base>=4.14 but both time-1.12 and time-1.12.1 require base>=4.13. ↩

[andreabedini]

@philderbeast In #8079 I had inlined the conditionals but failed to reflect that in the version bounds.

It looks like we'll need to bump to base>=4.13 or even base>=4.141 because of the time>=1.12 constraint in cabal.project. That equates to ghc>=8.8 or ghc>=8.10.

I am not sure what you mean here, we still have GHC 8.4 in CI.

[philderbeast]

I am not sure what you mean here, we still have GHC 8.4 in CI.

I was looking at the default --project-file=cabal.project but CI uses --project-file=cabal.validate.project that doesn't have the extra time constraints. Could we use project imports to ensure both projects pick up the same constraints?

[Mikolaj]

I was looking at the default --project-file=cabal.project but CI uses --project-file=cabal.validate.project that doesn't have the extra time constraints. Could we use project imports to ensure both projects pick up the same constraints?

Great minds think alike: #9372 (comment)