ghc support deprecation schedule

[jneira]

• As we have several issues about i think it is useful to unify all of them and inform users of our plans to deprecate ghc support.
• ghc support is the main source of ci consumption resources so we need to have the right balance between user needs and them
• otoh we have a huge amount of cpp'd code based on ghc version which can be removed (or even entire packages as hie-compat
• The proposed schedule could be:

condition	removed ghc versions	supported ghc versions
after next release 1.4.0 with 8.10.7	8.10.4, 8.10.3, 8.10.2, 8.8.3, 8.6.4	9.0.1 (partial), 8.10.7, 8.10.6, 8.10.5, 8.8.4, 8.6.5
with full support for ghc-9.0	8.6.5	9.2.* (partial)?, 9.0.*, 8.10.7, 8.10.6, 8.10.5, 8.8.4
with full support for ghc-9.2	8.10.6, 8.10.5, 8.8.4	9.2.* , 9.1.*, 8.10.7

• We should announce this schedule in all comm channels and remind it in the previous to deprecation hls version
• It could change after any reasonable user feedback
• "full support" has to be defined but
  • it should include all plugins and features
  • the full supported ghc should be supported as well by a stack lts snapshot
• haskell-language-server-wrapper will continue to choose haskell-language-server-8.10.6 f.e. whatever would be the hls own version, so users will be able to continue using older versions of hls for deprecated ghc's

//cc @pepeiborra @Ailrun @ndmitchell @mpickering @wz1000 @berberman @isovector @hasufell

[hasufell]

I'd suggest to support at most 2 GHC versions in a X.Y branch. So 8.10.7 and 8.10.6, but not 8.10.5.

[jneira]

I'd suggest to support at most 2 GHC versions in a X.Y branch. So 8.10.7 and 8.10.6, but not 8.10.5.

That would be the general criteria but i am afraid that 8.10.6 was a somewhat failed 8.10.7 so i think it worths to keep 8.10.5 a little bit but give users some more time to jump from 8.10.6 to 8.10.7

[jneira]

Thanks to @maralorn's question in matrix it worths to note that haskell-language-server-wrapper will continue to choose haskell-language-server-8.10.6 whatever would be the hls own version, so users will be able to continue using older versions of hls for deprecated ghc's

[pepeiborra]

I would be against dropping 8.8 support if we landed "full 9.2 support" tomorrow.

One way to encode my reservation would be including "Stackage Nightly" or even "Stackage LTS" as a condition for "full support". I.e. a GHC version is not considered mature until it has full support from HLS and from Stackage

[jneira]

totally agree, updated the issue description

[hasufell]

I would be against dropping 8.8 support if we landed "full 9.2 support" tomorrow.

I agree. That's why I think it's more worthwhile to support many X.Y versions, but as few X.Y.Z combinations. Industry users may have several reasons to lack behind significantly. However, updating from 8.10.5 to 8.10.7 is little to no effort, since base/core libs are usually PVP compatible.

I.e. a GHC version is not considered mature until it has full support from HLS and from Stackage

I don't think HLS needs a notion of "mature GHC" even. And cabal users may disagree what mature means. But we need a notion of "legacy".

[cdsmith]

I'd suggest to support at most 2 GHC versions in a X.Y branch. So 8.10.7 and 8.10.6, but not 8.10.5.

The current version of HLS doesn't support anything after 8.10.5. If HLS's next release dropped support for GHC 8.10.5, there would be no way to upgrade HLS without simultaneously upgrading GHC. That's really bad user support.

[hasufell]

The current version of HLS doesn't support anything after 8.10.5. If HLS's next release dropped support for GHC 8.10.5, there would be no way to upgrade HLS without simultaneously upgrading GHC. That's really bad user support.

Good point. I think given all the information in this thread we could easily write a simple policy anyone doing a release can follow.

[cdsmith]

I am currently working on getting HLS working in a (work) setting that's still using GHC 8.6.5. It would be disappointing if I finished this project, only to have it become harder to install HLS for 8.6.5. I take some consolation in the fact that older versions of HLS would still be available. If software like the VSCode Haskell extension could be aware of this and be willing to install those older versions without pulling teeth, that would be even better.

[Ailrun]

I know that it causes a lot of maintenance issues to have all those versions, but I'm also against dropping GHC 8.6.5. It is quite a well-working version in many systems, and I often meet (industrial, non-public) projects using GHC 8.6.5, not later, for exactly that reason. I think we should support at least the latest version for each X.Y version until really most of the ppl (like < 0.5% or so) (based on Haskell survey or something) move to some other minor versions or something.

[jneira]

I am currently working on getting HLS working in a (work) setting that's still using GHC 8.6.5. It would be disappointing if I finished this project, only to have it become harder to install HLS for 8.6.5. I take some consolation in the fact that older versions of HLS would still be available.

I am with you, i know 8.6.5 is a beloved version and myself, as a windows user, have been using it for a long time cause it was the unique reliable ghc version in windows, until 8.10.5 arrived.

But hls relies heavily in features added in ghc-8.8 (hie files), we have to maintain an entire package to get compat with 8.6.5 (hie-compat). At some point we will no able to leverage new ghc features cause making it compatibles will not be possible (or not feasible/reliable given our resources).

If software like the VSCode Haskell extension could be aware of this and be willing to install those older versions without pulling teeth, that would be even better.

That is a really good idea, not sure if other installation tools (ghcup?) could be improved for that

I think we should support at least the latest version for each X.Y version until really most of the ppl (like < 0.5% or so) (based on Haskell survey or something) move to some other minor versions or something.

Mmm, i like to be conservative with deprecations, but maybe that requirement is too hard imo, given users could continue using old versions of hls. Well the ghc team itself is not maintaining those versions and users continue using them, without new bug fixes or features.

What about move version deprecation and keep 8.6.5 until 9.2.* is widely used?

[pepeiborra]

If an industrial user is still on 8.6.5 after we drop support, they should be happy to stick to an old version. After all, they already stick to old versions of all the packages they use and have decided that this is preferable (cost-wise) than upgrading their compiler. So I don't think we should encumber our most important cohort (OSS contributors and maintainers) with a slower deprecation schedule for the benefit of organisations who have already decided that sticking to older versions is fine.

Summarising the contents of this thread that have wider agreement:

• A GHC version is legacy if it is 3 or more major versions away from the newest Stackage LTS.
• HLS will build on all non-legacy (major) versions of GHC,
• For every non-legacy major GHC version, HLS will provide binaries for as many GHC releases as reasonable (usually 2, but can be more).
• We may extend the HLS wrapper to find & download older HLS binaries when it detects a legacy GHC version

[jneira]

* For every non-legacy major GHC version, HLS will provide binaries for as many GHC releases as reasonable (usually 2, but can be more).

I would say that it could be one too (to keep only 8.6.5 and 8.8.4 at some point)