Skip to content

Add ghc deprecation policy to documentation #2231

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Sep 23, 2021
Merged

Add ghc deprecation policy to documentation #2231

Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
46d1a86
Create ghc-deprecation.md
jneira Sep 22, 2021
97e4416
Mark 8.8.3 with *
jneira Sep 22, 2021
567c961
Add deprecation to index
jneira Sep 22, 2021
4c814a8
dont use bullet list for prose
jneira Sep 22, 2021
764f414
Move ghc support plan
jneira Sep 22, 2021
482695b
Rephrasing
jneira Sep 22, 2021
7548954
Tweak support docs (#2232)
michaelpj Sep 22, 2021
da0b931
Include pepe suggestions
jneira Sep 22, 2021
d0884ad
More precisions
jneira Sep 22, 2021
503bc7b
Merge branch 'master' into jneira-patch-1
jneira Sep 23, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions docs/ghc-deprecation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
# GHC support deprecation policy

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

## Deprecation policy

- A GHC version is legacy if it is 3 or more major versions away from the newest stackage LTS ghc version
- HLS will build on all non-legacy (major) versions of GHC,
- for the latest major GHC version we will support at least 2 minor versions
- for the rest of major supported GHC versions we will support at least the latest GHC minor version in stackage LTS (so 1 minor version)
- 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


| newest LTS ghc version | supported ghc versions |
|------------------------|-------------------------------------------------|
| 8.10.7 | 8.10.7, 8.10.6, 8.10.5(\*), 8.8.4, 8.8.3, 8.6.5 |
| 9.0.1 | 9.0.1, 8.10.7, 8.8.4, 8.6.5(\*) |
| 9.0.2 | 9.0.2, 9.0.1, 8.10.7, 8.8.4, 8.6.5(\*) |
| 9.2.0 | 9.2.0, 9.0.2, 8.10.7, 8.8.4 |

- versions with `*` are versions which should be removed accordingly to the policy but we will keep due to the specific history of realibilty of recent ghc versions
- this prevision is not definitive and may vary depending on changes in the criteria listed above (but always honouring the policy)