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:
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.
We establish a concrete stability policy to this effect, and announce it far and wide.
etc. (whatever we come up with here as refinements)
Whatever we come up with as a result of conversation
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?
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.
they are 32 (GHC < 8.0 option should not have been affected by the survey bug), so ≃ 2,4% of people who filled the survey;
alas they mostly are professional users:
`Do you use Haskell at work?` n
1 No, and I don't want to 2
2 No, but I'd like to 5
3 No, but my company does 1
4 Yes, some of the time 7
5 Yes, most of the time 16
6 NA 1
less than half of them uses cabal:
cabalOrStack n
1 Cabal only 6
2 Cabal and Stack 6
3 Stack only 15
4 NA 5
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.
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.
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.
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.
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)
