Add ghc deprecation policy to documentation #2231
Conversation
jneira
requested review from
pepeiborra,
ndmitchell,
michaelpj,
Ailrun and
berberman
jneira
changed the title
docs/ghc-deprecation.md
Outdated
| - We may extend the existing discovery mechanisms (hls-wrapper, automatic download in vscode extension) to find and download older HLS binaries when it detects a legacy GHC version | ||
| - We will warn users about the deprecated ghc version in the notes of the release *prior* to the deprecation itself. | ||
|
|
||
| ## Deprecation prevision |
There was a problem hiding this comment.
I think this is not the table that our users actually care about. Our users probably want to know which GHC versions are supported now, and how will that change in future.
Maybe that should be a separate table. I suggest something like this (content is random since I don't know off the top of my head!)
| GHC version | Supported | Future status |
|---|---|---|
| 9.2.* | Partial | Full support in 1.4.0.0 |
| 8.10.{7,6} | Y | Supported unitil some LTS thing happens |
| 8.6.5 | Y | Will be deprecated in 1.4.0.0 |
| 7.10 | N |
Then we can link to this policy to explain when support gets dropped.
There was a problem hiding this comment.
hmm i am afraid that it will not depend on the hls version itself, only on stackage lts but i got the idea
do you think that separate table should live in that document or in other place more visible?
|
You need to reference this in |
Co-authored-by: Julian Ospald <hasufell@posteo.de>
And update description to match the github project one
Sure, thanks for noting it, done |
|
I thought we agreed that policy exceptions have no place in the policy. As such, we should remove |
Yeah but the policy itself is clean (
So we could decide to drop ghc-8.6.5 and "simply" update the prevision (although i would not change it) Maybe we can move the table out of there as @michaelpj suggested and let the policy itself clean of facts. |
docs/ghc-deprecation.md
Outdated
| - `haskell-language-server`(HLS) is highly tied to ghc api so much so that it needs a specific flavour for each ghc minor version to ensure it will work in a reliable way | ||
| - It supposes the codebase is riddled with code conditioned to each supported ghc versions. It even needs entire packages to fully support older versions of ghc. | ||
| - Our continouos integracion setup has to cover all those cases so it have to use lot of resources to test and build the executable. | ||
| - So we need to limit the ghc support to save maintainers and contributors time and reduce ci resources consumption. It becomes vital to make HLS development manageable. | ||
| - At same time we aim to support the right balance of ghc versions to minimize impact to final users who usually needs to keep using older ghc versions, even if they are out of the window support offered by ghc itself. | ||
| - To establish the policy and the possible exceptions we aim to take in account: | ||
| - completeness of support: the GHC flavour should include all plugins and features | ||
| - ghc versions supported by newer [stackage](https://www.stackage.org/) LTS's | ||
| - ghc versions supported by default in the most popular [linux distributions](https://repology.org/project/ghc/versions) | ||
| - the specific history of ghc releases and their realibility on the major operating systems (linux, windows, macos) | ||
| - It worths to note that users of deprecated ghc versions always will have the option of: | ||
| - Continue using the last HLS with support for their ghc version. So they will miss new bug fixes and features. | ||
| - For deprecated minor versions of a still supported major version, try to build HLS from source. | ||
| - We will not guarentee it will work but will do quite likely. | ||
|
|
There was a problem hiding this comment.
| - `haskell-language-server`(HLS) is highly tied to ghc api so much so that it needs a specific flavour for each ghc minor version to ensure it will work in a reliable way | |
| - It supposes the codebase is riddled with code conditioned to each supported ghc versions. It even needs entire packages to fully support older versions of ghc. | |
| - Our continouos integracion setup has to cover all those cases so it have to use lot of resources to test and build the executable. | |
| - So we need to limit the ghc support to save maintainers and contributors time and reduce ci resources consumption. It becomes vital to make HLS development manageable. | |
| - At same time we aim to support the right balance of ghc versions to minimize impact to final users who usually needs to keep using older ghc versions, even if they are out of the window support offered by ghc itself. | |
| - To establish the policy and the possible exceptions we aim to take in account: | |
| - completeness of support: the GHC flavour should include all plugins and features | |
| - ghc versions supported by newer [stackage](https://www.stackage.org/) LTS's | |
| - ghc versions supported by default in the most popular [linux distributions](https://repology.org/project/ghc/versions) | |
| - the specific history of ghc releases and their realibility on the major operating systems (linux, windows, macos) | |
| - It worths to note that users of deprecated ghc versions always will have the option of: | |
| - Continue using the last HLS with support for their ghc version. So they will miss new bug fixes and features. | |
| - For deprecated minor versions of a still supported major version, try to build HLS from source. | |
| - We will not guarentee it will work but will do quite likely. | |
| `haskell-language-server`(HLS) is highly tied to the ghc api.This imposes a high maintenance cost: | |
| - The codebase is littered with conditional logic, | |
| - We own auxiliary packages to support older versions of ghc. | |
| - CI has to cover all the supported versions. | |
| So we need to limit the ghc support to save maintainers and contributors time and reduce CI resources. | |
| At same time we aim to support the right balance of ghc versions to minimize impact to final users. | |
| To establish the policy we take into account: | |
| - completeness: support includes all plugins and features | |
| - 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) | |
| It is worth noting that users always will have the option of: | |
| - using the last HLS with support for their ghc version. | |
| - build HLS from source. |
There was a problem hiding this comment.
It looks cleaner, thanks, but why does it remove the specific history of ghc releases and their realibility...?
I think this is the real reason behind keep 8.6.5 and 8.10.5 and it is previsible that we should take that in account, even being an ambiguous consideration
There was a problem hiding this comment.
Is it? I thought we are not making any exceptions and therefore not keeping 8.6.5, and for 8.10.5 the reason was a Linux distro.
I removed because it's poorly defined and likely to lead to disagreements, and I don't think it's needed.
There was a problem hiding this comment.
Well , we disagree here i think users will like to know we aim to be flexible and will listen their opinion about their use cases and ghc versioning. It is more a statement of principles than a definition.
Maintainers will have always the last word.
Yes. Policy table is to help maintainers, not users. For users we can write a support plan somewhere else. |
Great, where could be a better place? A dedicated document? EDIT: features? |
|
ghc release plan/history moved to installation, maybe not the better place |
|
I started having a look and I ended up with #2232, feel free to take any of it you like. |
@michaelpj i prefer the structure of your version, so will close this directly. |
I'd prefer if you or Michael do it. |
|
Ops, michaelpj pr was against this |
docs/supported-versions.md
Outdated
| | 9.2.0 | not supported yet | | | ||
| | 9.0.1 | [current](https://github.com/haskell/haskell-language-server/releases/latest) ([partial](https://github.com/haskell/haskell-language-server/issues/297)) | | | ||
| | 8.10.7 | [current](https://github.com/haskell/haskell-language-server/releases/latest) | | | ||
| | 8.10.6 | [current](https://github.com/haskell/haskell-language-server/releases/latest) | will be deprecated after LTS for ghc-9.0 | |
There was a problem hiding this comment.
Which one will come first, full 9.0.1 support or stackage LTS for 9.0? If it's the former (and I think this is more likely to happen), I think it's maybe better to mention that one instead of this, or both.
(In "both" case, we may say
will be deprecated after complete support of GHC 9.0 as mentioned in this section
with link to the last section on "this section")
There was a problem hiding this comment.
Finally i used will be deprecated after LTS and HLS full support for.., hope it is complete enough
There was a problem hiding this comment.
Hmmmm, sounds like we need a term for "a fully supported major version of GHC with a LTS snapshot". That's also important for defining the major version support window. Perhaps the "mainline" GHC version? Then we could say "will be deprecated when 9.0 becomes mainline"?
Co-Authored-By: @pepeiborra
Ok, i've included your suggestions, introducing again a rephrased mention to reliability of ghc versions on os's. @pepeiborra thoughts about the new phrasing? |
|
this needs clearly a consensus between maintainers so i would ask you to approve explicitly it or expose the cocerns about the actual version, thanks all! |
//cc @cdsmith @juhp @hasufell and everyone else!