I’m just trying to understand why (for example) LTS 2.22 wouldn’t work with GHC 9.x.x as GHC pretends to be backward compatible.
From my experience, the incompatibility come from breaking in Base (even though I’m not sure why GHC couldn’t compile older version of Base) and Template Haskell, which exposes the internal guts of GHC and therefore breaks every time a change is made.
I was wondering if you’ve seen other problems.
2 Likes
Stack 2.13.1 did not support versions of Cabal (the library) older than Cabal-1.24.0.0, so projects using snapshots earlier than lts-7.0 or nightly-2016-05-26 will not build with Stack 2.13.1. EDIT: Stack builds using Cabal (the library) - specifically, it uses the version of Cabal that ships with the specified version of GHC. EDIT2: The significance of GHC 8.4.1 is that it was the first GHC to ship with Cabal >= 2.2.
I guess the reason is that LTS 2.22 fixes a specific version of base, and the version of base is strongly coupled to the version of GHC. AFAIK there currently is no way to compile an older version of base with a newer version of GHC. (But I think there are ongoing proposals and ongoing work to decouple the base version from the GHC version)
I guess I could always update the version of the stack executable with ghcup in tandem with the snapshot that I use. That is a completely workable solution for me. I just wanted to point out my usecase for older snapshots, since you explicitly asked for such usecases 
2 Likes
The problem with trying a project-level configuration of Stack like:
resolver: lts-6.35 # GHC 7.10.3
compiler: ghc-9.6.3
is indeed upper bounds on base in the project packages or their dependencies. Stack will warn if you try to upgrade or downgrade the base package (as an extra-dep) relative to the version that ships with the specified version of GHC.
EDIT: If you can work around those upper bounds, then such a configuration can work. For example, for a toy package that depends on acme-missiles-0.3:
resolver: lts-6.35 # GHC 7.10.3
compiler: ghc-9.6.3
extra-deps:
- acme-missiles-0.3
# lts-6.35 specifies stm-2.4.4.1
- stm-2.5.1.0 # stm-2.4.4.1 has base < 4.11
No there’s far more than just base and template-haskell. A biggie is simplified subsumption, but there are changes to advanced type checking features, records, etc. I would say GHC is most certainly not backwards compatible. Though it’s also not a million miles away, I think backwards compatible is fairly binary - you either are or you aren’t.
2 Likes
…today, tomorrow, this week, next week, this month, next month, this year or next year? Or on average? I think a more definite answer is being asked for here.
The cabal solver allows you to go back in time.
…then it must be perfect for this sort of work:
But how exactly does that feature help with deciding what GHC versions should no longer be supported by Stack?
I can provide some context. Currently, the Stack project says this:
A Stack executable makes use of Cabal (the library) through a small ‘Setup’ executable that it compiles from Haskell source code. The executable compiles that code with a dependency on the version of Cabal that ships with the specified GHC compiler. Each release of Stack will aim to support all versions of GHC and the Cabal package in Stackage snapshots published within seven years of the release. For example, snapshot LTS Haskell 8.0, published on 12 February 2017, was the first LTS Haskell snapshot to provide GHC 8.0.2 which comes with base-4.9.1.0 and Cabal-1.24.2.0. Until, at least, 13 February 2024, Stack releases would aim to support the immediate predecessor, GHC 8.0.1 and base-4.9.0.0, Cabal-1.24.0.0 and Haddock 2.17.2.
The origin of the ‘seven years’ was a discussion with users about their needs. The equivalent period for Cabal (the tool) is three years. Michael Snoyman’s stated general approach was ‘the last three major versions of GHC’ (approximately 1.5 years, at the current rate of release of GHC versions). I suggested ‘five years’, but (at that time) one person who participated wanted to continue to use the beloved GHC 7.10.3. ‘Seven years’ accomodated that person, at that time. GHC 7.10.3 is now not supported by Stack 2.13.1 (as more than seven years have passed).
Now, @theobat has got Stack to the point where it can build packages that depend on the public sub-libraries of other packages (I’ll anounce that properly at the time of the next release) and he is thinking ahead to component-based builds, which would be a precursor if Stack is ever to support Backback (in its current form). That requires Cabal >= 2.2. Catering for pre-Cabal 2.2 backwards compatibility would increase the complexity of those plans. So, there is a ‘cost-benefit’ consideration. The purpose of my question asked here (and elsewhere) is to collect information relevant to understanding better the practical ‘cost’ for users (if any) of the next version of Stack not supporting GHC versions before GHC 8.4.1. The responses that go to my question are informative but not necessarily determinative of the decision that needs to be taken.
5 Likes
Based on that seven-year support period, when would Stack jettison GHC versions older than 8.4.1?
GHC 8.4.1 (released 8 March 2018) comes with Cabal-2.2.0.0, and Stackage LTS Haskell 12.0 (released 9 July 2018) specified GHC 8.4.3/Cabal-2.2.0.1 (bumping from GHC 8.2.2) - so, strictly, 10 July 2025.
I presume from this comment:
…there is support for $GHC_VERSION < 8.4.1 already.
Can we then assume it’s the adding of the component-based build feature to Stack which is made more complicated by Stack supporting those older GHC versions until 10 July 2025?
Yes because currently we only build everything a package has to offer “the old way”, that is by letting cabal deal with the components of a package (mostly). It’s the per-package configure/build/register scheme which enforces a minimal version of cabal.
1 Like
How long would it take (an estimate) to have a working prototype of Stack:
- without support for Cabal 2.2,
- and support for component-based builds?
I would suggest just to drop support for ghc < 8.4 at the same time or as part of the PR to support component-based builds - I don’t see a need to remove it before that, is that too naive? Or maybe that is what you are asking about anyway?
I think don’t think it is that unusual: building old projects is exactly the use-case for why it is desirable for stack to work with old ghc’s. Of course a workaround would be to use stack-2.13 say for those.
I think @theobat has already realised from my series of questions that I was going to suggest that by the time Backpack support in Stack was ready for general use, the seven-year of support for $GHC_VERSION < 8.4 would have lapsed anyway. At that point, the working prototype supplants its predecessor to be the primary Stack codebase.
Of course, there’s the chance that working-prototype Backpack support could appear before 10 July 2025: one problem at a time…