Drop support for GHC 8.10 #3434
Conversation
michaelpj
force-pushed
the
mpj/drop-8.10
branch
from
94ac991 to
a8c0888
Compare
|
I'm against it. The 2022 Haskell survey results show that almost half of users are still on 8.10.x: https://taylor.fausak.me/2022/11/18/haskell-survey-results/#s2q4 It seems quite radical to drop it. |
|
Assuming 1.9.0.0 is fairly stable, GHC 8.10.7 users may use that for the foreseeable future, or are we expecting even more groundbreaking performance improvements for HLS and GHC 8.10.7? |
|
I misremembered. Our policy says that we support three major GHC versions back from a version that has full support from HLS and is in a stackage LTS. The latest stackage LTS is 9.2 not 9.4. So 8.10 is still in our support window until that happens. I'll leave this open for now since I did most of the work already. |
The policy is a policy, not a rule. And it doesn't make sense in this case unless we want to annoy half of our userbase. |
|
The policy is also a justification. Dropping versions will always annoy people, part of the reason for having a policy is so there's something we can point at and say, "look, we have to do something, here's this reasonable policy that says why we're doing it, do you disagree with that?". |
|
Sure, I'll send a PR to update the policy then. |
hasufell
requested review from
hasufell,
Anton-Latukha,
Ailrun,
isovector,
konn,
santiweight,
berberman,
kokobd,
July541 and
pepeiborra
as code owners
|
No, the policy is fine, I misremembered and this PR is premature, see my earlier comment. We should not drop 8.10 according to the policy. |
As one of the initiators of the policy, I disagree. |
|
Please for the love of God I urge you not to deprecate 8.10, its latest minor (8.10.7) is one of the most used GHC version, it has wonderful support in the ecosystem while still being quite reliable in terms of code generation. |
|
Just to reiterate:
|
Please correct me if I'm wrong but does that mean that there won't be patch releases for the last HLS to support 8.10.7? (note: I'm not trying to make you say anything, I just need to get a grasp on the whole thing) |
Yeah I think there never really have been long-running branches and my intuition says that would be more work than keeping that CPP code in |
|
This is maybe a bit out of scope, but for context: There might be some large libraries that aren't ready / released for ghc 9.x. If I'm not mistaken |
|
I want to revisit this. I think it is a good time. Stackage LTS is on 9.4. 8.10.7 was released in 2021. The compiler has not received any bug fixes since then, I think it is not so bad that 8.10-compatible HLS will now no longer receive bug fixes. Other than that the existing releases will continue to work perfectly well. |
|
I have updated the PR, it compiles and passes everything. |
|
We're going to do a release next week, though, this can wait until after that. |
michaelpj
force-pushed
the
mpj/drop-8.10
branch
from
bcc793e to
9511853
Compare
michaelpj
force-pushed
the
mpj/drop-8.10
branch
from
9511853 to
be86550
Compare
|
Okay, it's green now. I can't make the pre-commit check green because stylish-haskell chokes on a file and I can't figure out why. But I've updated the formatting as much as possible. |
There was a problem hiding this comment.
For line 84: stylish-haskell doesn't like function body and arguments to be separated like that. I think you might be able to move just the "=" over to the function body section and get it to work. Otherwise, you'll need to duplicate the function twice.
There was a problem hiding this comment.
Thanks, I'll fix this separately so I can get this in for now.
|
Can haskell-language-server-wrapper handle different versions of HLS? (My guess would be no?) |
|
It only knows about the HLS versions on PATH, iirc, so kind of? |
Per our support policy, we should now deprecated 8.10. We might not want
to do this immediately, but this PR implements it.
TODO: