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:
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.
…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.
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.
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.
…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.
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…