From 93b12196e4687b570fe6557b999872a50bdb21c0 Mon Sep 17 00:00:00 2001 From: Julian Ospald Date: Wed, 4 Jan 2023 20:49:07 +0800 Subject: [PATCH 1/7] Refine GHC deprecation policy --- docs/support/ghc-version-support.md | 48 ++++++++++++++++++++++------- 1 file changed, 37 insertions(+), 11 deletions(-) diff --git a/docs/support/ghc-version-support.md b/docs/support/ghc-version-support.md index 488a5a1310..69779925d2 100644 --- a/docs/support/ghc-version-support.md +++ b/docs/support/ghc-version-support.md @@ -75,7 +75,11 @@ Major versions of GHC which are not supported by HLS on master are extremely unl ## GHC version deprecation policy -### Major versions +### Base policy + +This is the static part of the policy that can be checked by a machine. + +#### Major versions A major GHC version is a "legacy" version if it is 3 or more major versions behind the latest GHC version that is @@ -86,12 +90,43 @@ For example, if 9.2 is the latest major version fully supported by HLS and used HLS will support all non-legacy major versions of GHC. -### Minor versions +#### 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). +### Extended policy + +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 also 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) +- The [Haskell Survey results](https://taylor.fausak.me/2022/11/18/haskell-survey-results/#s2q4) + +### Supporting a GHC version beyond its shelf life + +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. + +In case of maintenance burden concerns, the following process should be followed: + +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 + ### Announcements We will warn users about the upcoming deprecation of a GHC version in the notes of the release *prior* to the deprecation itself. @@ -107,12 +142,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) From 4e39448ffaadc5b25f3991932809d431017432a0 Mon Sep 17 00:00:00 2001 From: Julian Ospald Date: Thu, 19 Jan 2023 13:35:05 +0100 Subject: [PATCH 2/7] Update docs/support/ghc-version-support.md Co-authored-by: Michael Peyton Jones --- docs/support/ghc-version-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/support/ghc-version-support.md b/docs/support/ghc-version-support.md index 69779925d2..d2dc46e916 100644 --- a/docs/support/ghc-version-support.md +++ b/docs/support/ghc-version-support.md @@ -116,7 +116,7 @@ To establish and apply the policy we also take into account: 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. -In case of maintenance burden concerns, the following process should be followed: +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) From 9b995aac0924464218da55ca4a2a08d1f9836ef6 Mon Sep 17 00:00:00 2001 From: Julian Ospald Date: Thu, 19 Jan 2023 13:35:22 +0100 Subject: [PATCH 3/7] Update docs/support/ghc-version-support.md Co-authored-by: Michael Peyton Jones --- docs/support/ghc-version-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/support/ghc-version-support.md b/docs/support/ghc-version-support.md index d2dc46e916..17fd3b95f3 100644 --- a/docs/support/ghc-version-support.md +++ b/docs/support/ghc-version-support.md @@ -111,7 +111,7 @@ To establish and apply the policy we also take into account: - 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) -### Supporting a GHC version beyond its shelf life +### 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. From a917e54ed5c6743d85fc04a578c2431a6e0f3fdd Mon Sep 17 00:00:00 2001 From: Fendor Date: Fri, 14 Jun 2024 11:11:17 +0200 Subject: [PATCH 4/7] Reword to support status, as this is mentioned above --- docs/support/ghc-version-support.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/support/ghc-version-support.md b/docs/support/ghc-version-support.md index 17fd3b95f3..3e5947e7af 100644 --- a/docs/support/ghc-version-support.md +++ b/docs/support/ghc-version-support.md @@ -84,7 +84,7 @@ This is the static part of the policy that can be checked by a machine. A major GHC version is a "legacy" version if it is 3 or more major versions behind the latest GHC version that is 1. Fully supported by HLS -2. Used in the a Stackage LTS +2. Used in a Stackage LTS snapshot 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. @@ -103,9 +103,9 @@ by a discussion. #### Ecosystem factors -To establish and apply the policy we also take into account: +To establish and apply the policy we take the following ecosystem factors into account: -- Completeness: support includes all plugins and features +- Support status of HLS - 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) @@ -114,7 +114,8 @@ To establish and apply the policy we also take into account: ### 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. +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: From 9633326ca1b008eeaefb1d78298e27aeabd42ade Mon Sep 17 00:00:00 2001 From: Fendor Date: Sat, 15 Jun 2024 11:03:50 +0200 Subject: [PATCH 5/7] Include ghcup recommended version in support discussion --- docs/support/ghc-version-support.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/support/ghc-version-support.md b/docs/support/ghc-version-support.md index 3e5947e7af..d4c38901ae 100644 --- a/docs/support/ghc-version-support.md +++ b/docs/support/ghc-version-support.md @@ -83,11 +83,14 @@ This is the static part of the policy that can be checked by a machine. A major GHC version is a "legacy" version if it is 3 or more major versions behind the latest GHC version that is -1. Fully supported by HLS -2. Used in a Stackage LTS snapshot +1. Fully supported by HLS (support status "full support") +2. Used in a Stackage LTS snapshot or the GHCup recommended version, whichever is lower. + * `min(ghcup recommended version, stackage lts snapshot)` 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. +Another example, if there is a Stackage LTS for GHC 9.6 and recommended version + HLS will support all non-legacy major versions of GHC. #### Minor versions @@ -107,6 +110,7 @@ To establish and apply the policy we take the following ecosystem factors into a - Support status of HLS - The most recent [stackage](https://www.stackage.org/) LTS snapshot +- 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) From a4907ff8cfb634094aaa69ddc6c32747f20851f6 Mon Sep 17 00:00:00 2001 From: Patrick Date: Sat, 15 Jun 2024 18:17:49 +0800 Subject: [PATCH 6/7] reword --- docs/support/ghc-version-support.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/docs/support/ghc-version-support.md b/docs/support/ghc-version-support.md index d4c38901ae..319c4c705a 100644 --- a/docs/support/ghc-version-support.md +++ b/docs/support/ghc-version-support.md @@ -81,13 +81,11 @@ This is the static part of the policy that can be checked by a machine. #### Major versions -A major GHC version is a "legacy" version if it is 3 or more major versions behind the latest GHC version that is +A major GHC version is a "legacy" version if it is a major versions behind the latest GHC version that is +used in a Stackage LTS snapshot or the GHCup recommended version, whichever is lower. +* `min(ghcup recommended version, stackage lts snapshot)` -1. Fully supported by HLS (support status "full support") -2. Used in a Stackage LTS snapshot or the GHCup recommended version, whichever is lower. - * `min(ghcup recommended version, stackage lts snapshot)` - -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. +For example, if 9.2 is the latest major version fully supported by HLS and used in a Stackage LTS, then the 9.1 major version and older will be legacy. Another example, if there is a Stackage LTS for GHC 9.6 and recommended version From bf91737031cea211b0af2f297e97d5c86bcc6fa2 Mon Sep 17 00:00:00 2001 From: Michael Peyton Jones Date: Sat, 15 Jun 2024 11:51:41 +0100 Subject: [PATCH 7/7] Reword --- docs/support/ghc-version-support.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/docs/support/ghc-version-support.md b/docs/support/ghc-version-support.md index 319c4c705a..46eece5a34 100644 --- a/docs/support/ghc-version-support.md +++ b/docs/support/ghc-version-support.md @@ -81,15 +81,17 @@ This is the static part of the policy that can be checked by a machine. #### Major versions -A major GHC version is a "legacy" version if it is a major versions behind the latest GHC version that is -used in a Stackage LTS snapshot or the GHCup recommended version, whichever is lower. -* `min(ghcup recommended version, stackage lts snapshot)` +HLS will support major versions of GHC until they are older than _both_ -For example, if 9.2 is the latest major version fully supported by HLS and used in a Stackage LTS, then the 9.1 major version and older will be legacy. +1. The major version of GHC used in the current Stackage LTS; and +2. The major version of GHC recommended by GHCup -Another example, if there is a Stackage LTS for GHC 9.6 and recommended version +For example, if -HLS will support all non-legacy major versions of GHC. +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 @@ -130,10 +132,6 @@ When we decide to keep on an old version, we should track it as follows: 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 -### Announcements - -We will warn users about the upcoming deprecation of a GHC version in the notes of the release *prior* to the deprecation itself. - ### Why deprecate older versions of GHC? `haskell-language-server`(HLS) is highly tied to the GHC API. This imposes a high maintenance cost: