I seek to understand how important it is in practice that the next version of Stack supports a version of GHC before GHC 8.4.1. If that is important to you, please can you flag it here.
I’m asking the same question in various places where Stack users may gather. I’ve also noted the responses to the most recent State of Haskell Survey.
Unix and filepath are dropping support for <8.6.
…and maybe some other important “keystone” libraries have dropped support for $GHC_VERSION < 8.8, or 8.10…and so on and so forth.
Surely it would be easier for e.g. the HF to nominate the oldest supported version of GHC which all tools, libraries etc can be expected to work with. There would be no more need to inquire publicly about what and when versions of GHC will and won’t be supported any more - the oldest supported version of GHC would be displayed somewhere easy to find on www.haskell.org for all to see.
FWIW, my general target is to support at least five years of GHC and library releases.
GHC 8.4.1 was released on 2018-03-08, which is more than five years ago, so removing Stack support for previous versions is no problem for me.
The GHC status page GHC Status · Wiki · Glasgow Haskell Compiler / GHC · GitLab shows that GHC <= 9.0 are “not recommended for use”, is this what @atravers was mentioning? It seems to be a pretty stringent target.
No:
But it does rather nicely illustrate my point about the lack of clarity on this matter.
That seems like overstepping boundaries.
This is purely from a GHC HQ point of view. I’m not sure the larger community always shares that notion.
Then let the “straw polls” continue!
Otherwise, and if this happens to be one - I vaguely recall someone here (on this Discourse) saying that one of the HF’s roles was to make the difficult decisions, if and when they appeared. But that was so long ago now that I can’t seem to find the actual message (or perhaps it’s just a memory error…)
Maybe @chreekat can elaborate on the GHC “support window”: how it’s decided and how are we (tool and library maintainers) supposed to interpret it.
Surely it would be easier for e.g. the HF to nominate the oldest supported version of GHC which all tools, libraries etc can be expected to work with.
Unless this comes with committed funding to help said tools and libraries comply with that support window, I don’t see that this is very viable. A major determinant of how wide a range of GHC versions a library or tool supports is how much work this is for the maintainers, and how willing they are to do that.
HLS, for example, supports a comparatively smaller range of GHCs than other tools mentioned here. This is partly just because it is so exposed to the GHC API that it is extra-painful to support more versions, making us less willing to have a wide support window.
If there was going to be a centralised policy, I’d be more keen to see the promotion of a few GHC versions to LTS status (perhaps as part of a wider LTS strategy joining up with Stackage, which has led the way here). Then it would be reasonable to request that people consider keeping support for LTS versions. In practice this happens informally: 8.10 was implicitly treated this way because of its popularity and stability, and my read is that 9.2 has recently replaced it in this position.
This is more of a positive vision: if the GHC team is committing to support a version long-term (and maybe even keep doing minor releases), then it is much more motivating for a tool or library to join in with that plan.
If the HF wanted to coordinate a LTS plan that would be nice. The other useful thing they could do would be to look after Taylor’s State of Haskell survey, which is one of the only ways we find out who is actually using which versions of GHC!
@bgamari or @mpickering would need to clarify what that means (perhaps by editing that page to include some explanation?).
As a general point, I hope there’s agreement in this thread (and wider community) that the maintainers for individual projects can and should specify the range of versions they feel capable of supporting with the resources they have.
That shouldn’t stop anyone from using historical versions, unless they’re vulnerable. That’s why “not recommended for use” isn’t very useful information. The support window has closed, that’s fine.
I have one usecase for supporting older versions of ghc/stackage snapshots. Quite often I do some “Haskell archeology” on old and abandoned Haskell research projects / research artefacts. I want to compile and explore them with modern tooling like HLS, so I often have to iteratively apply the last 5-10 years of breaking changes in the ecosystem. For this I sometimes start by running them with the oldest available stackage snapshot, and then I hop from one stackage snapshot to the next and fix the problems that come up. It is admittedly a bit of an unusual use-case, and I could find an alternative workflow, but this workflow has worked quite well for me.
Take #2:
…so which one is it?
I’m not asking for more older GHC versions to be kept going - if anything, a centralised lowest supported version could end up removing some of those older versions from regular support.
All I and others are asking for is a single lowest supported version to be specified for everyone rather than repeatedly doing these “straw polls”.
Does that mean that even thougn in theory (through the no/extension system) a new version of GHC should work with old code it is not the case ?
What type of breakage do you encounter ( is it Base or TemplateHaskell incompatibility )?
I think I never encountered any problems with GHC and its type inference itself. For example, I never ran into problems with typeclass resolution, type families, impredicative types or the like. I think I always have to fix code w.r.t. the Functor-Applicative-Monad proposal and the introduction of the MonadFail typeclass. Fixing those is relatively straightforward. But a lot of the projects I have been looking at do something with Haskell syntax, so they either use TemplateHaskell or the haskell-src-exts package. Also there are all the small changes in various packages over time which accumulate if a project hasn’t been touched for 10 years. And stackage snapshots give me an easy way to pick a specific state of the Haskell ecosystem, say 8 years ago, and to make the code run for that point in time. Then I can pick the next snapshot and make the code compatible with the Haskell ecosystem 7 years ago, and so on.
I think, ultimately, the cabal solver decides.
I might be missing something there. If it’s not GHC itself why the need to keep older version of GHC then ?
If I understand the proposal correctly, then the current version of the stack binary would no longer be able to compile, say, the stackage snapshot LTS 2.22, since that one only works with GHC 7.8.4. So I could no longer use the combination of stack + LTS 2.22 + GHC 7.8.4 to get an old project running again.