Skip to content

Refine GHC deprecation policy #3438

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 8 commits into from
Jun 15, 2024
Merged

Refine GHC deprecation policy #3438

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
93b1219
Refine GHC deprecation policy
hasufell Jan 4, 2023
4e39448
Update docs/support/ghc-version-support.md
hasufell Jan 19, 2023
9b995aa
Update docs/support/ghc-version-support.md
hasufell Jan 19, 2023
a917e54
Reword to support status, as this is mentioned above
fendor Jun 14, 2024
9633326
Include ghcup recommended version in support discussion
fendor Jun 15, 2024
37248df
Merge branch 'master' into refine-policy
soulomoon Jun 15, 2024
a4907ff
reword
soulomoon Jun 15, 2024
bf91737
Reword
michaelpj Jun 15, 2024
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
63 changes: 45 additions & 18 deletions docs/support/ghc-version-support.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,26 +75,62 @@ Major versions of GHC which are not supported by HLS on master are extremely unl

## GHC version deprecation policy

### Major versions
### Base policy

A major GHC version is a "legacy" version if it is 3 or more major versions behind the latest GHC version that is
This is the static part of the policy that can be checked by a machine.

1. Fully supported by HLS
2. Used in the a Stackage LTS
#### Major versions

For example, if 9.2 is the latest major version fully supported by HLS and used in a Stackage LTS, then the 8.8 major version and older will be legacy.
HLS will support major versions of GHC until they are older than _both_

HLS will support all non-legacy major versions of GHC.
1. The major version of GHC used in the current Stackage LTS; and
2. The major version of GHC recommended by GHCup

### Minor versions
For example, if

1. Stackage LTS uses GHC 9.2; and
2. GHCUp recommends GHC 9.4

then HLS will support back to GHC 9.2.

#### Minor versions

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

### Announcements
### Extended policy
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 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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Collaborator

Choose a reason for hiding this comment

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

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?


This is the part of the policy that needs evaluation by a human and possibly followed
by a discussion.

#### Ecosystem factors

To establish and apply the policy we take the following ecosystem factors into account:

- Support status of HLS
- The most recent [stackage](https://www.stackage.org/) LTS snapshot
Copy link
Collaborator

Choose a reason for hiding this comment

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

ditto

- The GHC version recommended by GHCup
- 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)
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 these three points are the interesting ones. I'd move them into the next section where they're used.

Copy link
Member Author

Choose a reason for hiding this comment

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

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?


We will warn users about the upcoming deprecation of a GHC version in the notes of the release *prior* to the deprecation itself.
### Supporting a GHC version beyond normal deprecation time

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.

When we decide to keep on an old version, we should track it as follows:

1. open a ticket on HLS issue tracker wrt discussing to deprecate said GHC version
- explain the reason the GHC version wasn't deprecated (context)
- explain the maintenance burden it causes (reason)
- evaluate whether it impacts the next HLS release (impact)
2. discuss whether ecosystem factors changed
- e.g. if Haskell Survey results show that 25% or more of users are still on the GHC version in question, then dropping should be avoided
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
Comment on lines +132 to +133
Copy link
Collaborator

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

True


### Why deprecate older versions of GHC?

Expand All @@ -107,12 +143,3 @@ We will warn users about the upcoming deprecation of a GHC version in the notes
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 the impact on users.

### What factors do we take into account when deprecating a version?

To establish and apply 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)
- The reliability of different ghc versions on the major operating systems (Linux, Windows, MacOS)
Loading