# RFC: Should Cabal drop support for GHC \< 8?

**URL:** <https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874>\
**Category:** Uncategorized\
**Created:** [August 11, 2021, 7:56pm UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874 "2021-08-11T19:56:54Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![emilypi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/emilypi/32/5307_2.png) [@emilypi](https://discourse.haskell.org/u/emilypi)\
**Post date:** [August 11, 2021, 7:56pm UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874/1 "2021-08-11T19:56:54Z")

</div>

Please see here: [RFC: Dropping build support for GHC \< 8 · Issue #7531 · haskell/cabal · GitHub](https://github.com/haskell/cabal/issues/7531)

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:

 ![image](https://us1.discourse-cdn.com/flex002/uploads/haskell/original/2X/7/759542f3b69aee4a472a685be6c1addb1dab2f09.png)

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.  
etc. (whatever we come up with here as refinements)
3. Whatever we come up with as a result of conversation

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [August 11, 2021, 8:11pm UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874/2 "2021-08-11T20:11:37Z")

</div>

What exactly does dropping support for old versions of GHC mean? Does it just mean the cabal packages cannot be built with old versions of GHC or does it also mean that building other packages with cabal will not work if an old version of GHC is installed on my system?

---

<div class="post-metadata">

**Author:** ![emilypi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/emilypi/32/5307_2.png) [@emilypi](https://discourse.haskell.org/u/emilypi)\
**Post date:** [August 11, 2021, 8:17pm UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874/3 "2021-08-11T20:17:21Z")

</div>

This would mean that we bump the `base` lower bound to support 8.0 at the least. It will not affect the ability of `cabal-install` or `Cabal` to work with libraries that require an earlier GHC, only that the actual library will not be built against them in particular on the source repo side, and we’ll stop dedicating CI power towards confirming our builds work with older GHCs.

---

<div class="post-metadata">

**Author:** ![f-a](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/f-a/32/2740_2.png) [@f-a](https://discourse.haskell.org/u/f-a)\
**Post date:** [August 11, 2021, 9:12pm UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874/4 "2021-08-11T21:12:14Z")

</div>

A note on those users:

- they are 32 (`GHC < 8.0` option should not have been affected by the [survey bug](https://github.com/haskellweekly/haskellweekly/issues/61)), so ≃ 2,4% of people who filled the survey;

- alas they mostly are professional users:

- less than half of them uses `cabal`:

---

<div class="post-metadata">

**Author:** ![emilypi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/emilypi/32/5307_2.png) [@emilypi](https://discourse.haskell.org/u/emilypi)\
**Post date:** [August 11, 2021, 9:29pm UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874/5 "2021-08-11T21:29:17Z")

</div>

Interesting, thanks for the context @f-a. I wish we had finer-grained statistics to tell us whether those older Cabal and Cabal+Stack users required up to date Cabal versions, and what their use-cases might be.

---

<div class="post-metadata">

**Author:** ![tcard](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tcard/32/4823_2.png) [@tcard](https://discourse.haskell.org/u/tcard)\
**Post date:** [August 11, 2021, 11:46pm UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874/6 "2021-08-11T23:46:21Z")

</div>

It is anecdotal, but my recent experience with such old versions of GHC was on legacy systems that are stuck on old OS releases. The projects use OS packages (for Haskell development tools as well as libraries), so old versions of Cabal are used as well. Dropping support in new versions would not be a problem in this case since new versions of Cabal are not used.

I find it surprising that most users of old versions of GHC are using Stack.

In general, I think that backwards compatibility is quite important for making Haskell a viable choice in industry. My personal opinion is that people using old versions of GHC can use the version of Cabal that was released with it, however, so I am more concerned with backwards compatibility of the packages on Hackage. Currently, my goal is to maintain software to work with five years of GHC/base and Cabal versions. (With respect to Cabal, this means that I have to refrain from using “new” features such as common stanzas.) GHC 8.0.1 was released on 2016-05-21, which is more than five years ago. This is just my personal goal, but I mention it because establishing a goal/policy based on such a time frame might be worth discussing/considering.

---

<div class="post-metadata">

**Author:** ![jhenahan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jhenahan/32/3578_2.png) [@jhenahan](https://discourse.haskell.org/u/jhenahan)\
**Post date:** [August 12, 2021, 12:22am UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874/7 "2021-08-12T00:22:35Z")

</div>

Is there a possible universe in which `cabal` the executable becomes a shim which downloads/compiles a `cabal-install-<version>` binary based on, say, compatibility with the installed version of GHC, or the specified `cabal-version`? One of the scant nice things I have to say about `sbt` is that it’s quite good on this point. I have strong guarantees that if the project built with _some_ version of `sbt` that I can run `sbt compile` today with whatever version I have installed and it still will.

---

<div class="post-metadata">

**Author:** ![emilypi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/emilypi/32/5307_2.png) [@emilypi](https://discourse.haskell.org/u/emilypi)\
**Post date:** [August 12, 2021, 12:29am UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874/8 "2021-08-12T00:29:29Z")

</div>

We have discussed an upgrade path that would look something like this, however it’s still in the early stages of discussion, and not at all fleshed out. What I _can_ say with certainty though, is that it’s on the table, and I’m happy to flesh out a proposal.

---

<div class="post-metadata">

**Author:** ![sclv](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/sclv/32/71_2.png) [@sclv](https://discourse.haskell.org/u/sclv)\
**Post date:** [August 16, 2021, 4:39pm UTC](https://discourse.haskell.org/t/rfc-should-cabal-drop-support-for-ghc-8/2874/9 "2021-08-16T16:39:20Z")

</div>

Cabal indefinitely maintains compat with older ghcs (in terms of building with them). So there’s no reason to ever go _backwards_ with cabal versions. As such, imho, just letting existing tooling (package managers, ghcup, cabal-install itself) manage upgrading cabal forward only seems like its good enough for me.

Sbt needs to go a different route because the config language is scala itself, so it needs to pull in a scala that can actually build the sbt file! (Unfortunate, but at least they put together a workable solution)