Refine GHC deprecation policy #3438
Conversation
hasufell
force-pushed
the
refine-policy
branch
from
9754252 to
6c568ef
Compare
|
The existing policy already demands to consider ecosystem factors, so adding the Haskell Survey as an input seems like a no-brainer (because it's one of the largest indicators for ecosystem questions). Additionally, it seems it wasn't very clear that there are two different parts of the policy: one that can be statically checked and one that can't. And that both parts need to be considered. As such, I tried to make that clearer by sectioning them. |
|
@michaelpj any opinions? |
|
|
||
| For the latest supported major GHC version we will support at least 2 minor versions. | ||
|
|
||
| For the rest of the supported major GHC versions, we will support at least the latest minor version in Stackage LTS (so 1 minor version). | ||
|
|
||
| ### Extended policy |
There was a problem hiding this comment.
I think the base/extended distinction is confusing and you could just drop these headers. It's fairly clear that the later sections talk about exceptions to the rules.
There was a problem hiding this comment.
Hm, I think we're having a slightly different perception.
I'm not seeing it as an exception rule that can be applied if someone speaks up about it.
Someone actually updating the supported GHC versions is required to check/consided both.
There was a problem hiding this comment.
Okay, yes, I agree with that. Then maybe we just want to add after line 81: "HLS may continue to support legacy GHC versions, see the section below on 'Supporting legacy GHC versions'" or something?
docs/support/ghc-version-support.md
Outdated
|
|
||
| To establish and apply the policy we also take into account: | ||
|
|
||
| - Completeness: support includes all plugins and features |
There was a problem hiding this comment.
This is already included above
There was a problem hiding this comment.
I don't understand this comment
There was a problem hiding this comment.
Included where?
Do you mean
Support status (see the support policy below for more details):
- "initial support": support for this GHC version is underway, but it is not ready to be released yet
- "basic support": this GHC version is currently actively supported, and all tier 1 plugins work
- "full support": this GHC version is currently actively supported, and most tier 2 plugins work
- "deprecated": this GHC version was supported in the past, but is now deprecated
?
There was a problem hiding this comment.
I rephrased this to make sure it is clear we are referring to the HLS support status.
Also, I made clear that we aim to list all factors.
| To establish and apply the policy we also take into account: | ||
|
|
||
| - Completeness: support includes all plugins and features | ||
| - The most recent [stackage](https://www.stackage.org/) LTS snapshot |
| - The most recent [stackage](https://www.stackage.org/) LTS snapshot | ||
| - The GHC versions used in the most popular [linux distributions](https://repology.org/project/ghc/versions) | ||
| - The reliability of different ghc versions on the major operating systems (Linux, Windows, MacOS) | ||
| - The [Haskell Survey results](https://taylor.fausak.me/2022/11/18/haskell-survey-results/#s2q4) |
There was a problem hiding this comment.
I think these three points are the interesting ones. I'd move them into the next section where they're used.
There was a problem hiding this comment.
I also don't understand this suggestion. This is the section about Ecosystem factors. Why would that go into the next section, which explains the process of supporting older GHCs?
docs/support/ghc-version-support.md
Outdated
| In cases where the base policy demands a deprecation, but ecosystem factors | ||
| suggest that it's still widely used (e.g. last [Haskell Survey results](https://taylor.fausak.me/2022/11/18/haskell-survey-results/#s2q4)), the deprecation should be suspended for the next release and the situation be re-evaluated for the release after that. |
There was a problem hiding this comment.
| In cases where the base policy demands a deprecation, but ecosystem factors | |
| suggest that it's still widely used (e.g. last [Haskell Survey results](https://taylor.fausak.me/2022/11/18/haskell-survey-results/#s2q4)), the deprecation should be suspended for the next release and the situation be re-evaluated for the release after that. | |
| Sometimes the policy suggests that we should deprecate a version of GHC, but doing so would be particularly harmful for our users because it remains very widely used. In cases like this we can decide to keep supporting that GHC version, but this decision should be revisited each time we do a release. | |
| To determine whether we should keep supporting a GHC version we can use | |
| - The GHC versions used in the most popular [linux distributions](https://repology.org/project/ghc/versions) | |
| - The [Haskell Survey results](https://taylor.fausak.me/2022/11/18/haskell-survey-results/#s2q4) | |
| - Anecdotal evidence about he reliability of different GHC versions on the major operating systems (Linux, Windows, MacOS), e.g. noting the presence of serious bugs |
There was a problem hiding this comment.
I think this is mixing up things. Ecosystem factors should be its own section and be referenced from this section explaining the process (not criteria) of supporting an older GHC version.
There was a problem hiding this comment.
I agree and think this separation helps the reader understanding what is going on.
| 3. if dropping is still undesired, but maintenance burden is also high, then set out a call-for-help and contact HF for additional funding to support this GHC version | ||
| 4. if no help or funding was received within 2 releases (say, e.g. 3-6 months), then drop the version regardless |
There was a problem hiding this comment.
I'm fine with this but we could also leave it out and just experiment with various ways of asking for help before we write it down
|
@michaelpj I think I'm not quite getting what you're proposing. I feel the sections are fine. The wording can definitely improved, but it's a running document. |
|
@michaelpj is there still some open discussion here? |
Co-authored-by: Michael Peyton Jones <me@michaelpj.com>
Co-authored-by: Michael Peyton Jones <me@michaelpj.com>
|
@michaelpj I think the wording and policy is fine and we should merge this. Would you mind reading through one more time? |
There was a problem hiding this comment.
I reword it a bit more. But I think we should still wait for @michaelpj to confirm
|
I reworded it some more. I also removed the section about announcements, since we haven't been doing that, and I think it seems in practice to not be that big a deal. |
* master: (36 commits) Migrate indexHieFile progress notification to ProgressReporting API (haskell#4205) Remove final allow-newer for 9.10 (haskell#4329) Remove unused exactprint dep More stylish Use newer cabal-fmt, partially lift ghc version restriction stylish Cleanup CI configs and cabal files More no-op code cleanup Remove no-longer-needed compat code, remove unused stuff Remove pre-multi component junk for GHC <= 9.2 Fix stylish Fix a few things Remove from CI Update docs Fix loss of 9.2 GHC version More CPP WIP evaluate CPP Prepare release 2.9.0.0 (haskell#4319) Add completion for import fields in cabal files (haskell#4305) Refine GHC deprecation policy (haskell#3438) ...
#3434