Drop compatibility with GHC 8.6.5

[pepeiborra]

No description provided.

[kokobd]

LGTM

[July541]

What made us make this decision?

[pepeiborra]

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.

[michaelpj]

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.

[pepeiborra]

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.

[michaelpj]

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.

[July541]

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.

[pepeiborra]

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

[michaelpj]

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.

[July541]

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!

[andys8]

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?

haskell-language-server/ghcide/src/Development/IDE/GHC/Compat/Core.hs

Line 39 in aad896c

#if MIN_VERSION_ghc(8,8,0)

[Ailrun]

@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.

[michaelpj]

We decided to drop 8.6 and 8.8 now 1.8.0 is out.

[andys8]

Should both 8.6 and 8.8 be dropped in this PR, or split into two?

[pepeiborra]

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

[andys8]

docs/supported-versions.md doesn't exist anymore. Was moved to docs/support/ghc-version-support.md.

[andys8]

Since this is an uncritical change to docs, I pushed changes directly to this PR to resolve the conflict.