haskell
Drop compatibility with GHC 8.6.5
The GHC version deprecation policy: https://haskell-language-server.readthedocs.io/en/latest/supported-versions.html
LTS is already on 9.0 and 8.6.5 is 3 major versions behind.
Happy to hear everyone's thoughts.
I think we decided to make a deliberate exception for 8.6.5, since at the time we wrote the policy it was still very widely used. I think we could probably get away with dropping it now, but if it's not a problem then I think we should wait for the 9.2 LTS simply because that's because what we've been saying that we're going to do.
but if it's not a problem then I think we should wait for the 9.2 LTS simply because that's because what we've been saying that we're going to do.
Fair enough, I didn't remember that we promised to keep 8.6.5 compat. until the 9.2 LTS. Moving forward, we should probably avoid committing to unknown future dates.
I'll keep the PR around, since I suspect (or hope!) that a 9.2 LTS is around the corner.
I mean, the only way we said we would do it is that line in the supported GHCs doc, but it has been there for a while so people might reasonably have some expectations about it.
People will be disappointed since our policy said we would drop 8.6.5 after we have fully supported ghc-9.2, there is still a long way to go.
But I agree to drop it without loud opposition before fully supporting ghc-9.2.
What does "full support" for 9.2 mean?
- Upgrade all plugins: We should not commit to this as each maintainer has their own schedule.
- Upgrade core plugins: A bit unclear since the set of core plugins is not specified anywhre
- Upgrade ghcide plugins: This has already been done, or mostly done
I think the LTS condition is also important. My understanding of that was that it acts as a proxy for how much of the ecosystem has upgraded, and hence for what our expectations about GHC versions used by our users can be.
I agree that "full support" is pretty ambiguous. We should try and pin that down. I think it would be good to identify a set of "core plugins", especially as we move in the direction of moving more basic stuff out of ghcide.
I think it would be good to identify a set of "core plugins", especially as we move in the direction of moving more basic stuff out of ghcide.
Can't more agree!
Two questions:
- Does this allow us to drop and simplify all macros where
MIN_VERSION_ghc(8,8,0)is used (because there is no lower supported ghc version)? - For my understanding: Does dropping support for a GHC version remove the support to compile hls with that version, or to use hls on a project with that version - or both?
https://github.com/haskell/haskell-language-server/blob/aad896cdc5b4869dc781e9b1eade8f3b14148f7c/ghcide/src/Development/IDE/GHC/Compat/Core.hs#L39
@andys8
Does this allow us to drop and simplify all macros where MIN_VERSION_ghc(8,8,0) is used (because there is no lower supported ghc version)?
Yes.
For my understanding: Does dropping support for a GHC version remove the support to compile hls with that version, or to use hls on a project with that version - or both?
For HLS, both go together. Once it becomes impossible to compile with a specific version, one cannot use HLS with a project using that version.
Should both 8.6 and 8.8 be dropped in this PR, or split into two?
I'm going to land this PR as is
Since this is an uncritical change to docs, I pushed changes directly to this PR to resolve the conflict.