doc: supported-versions: add notes on adding new GHCs #2548
Conversation
Anton-Latukha
changed the title
|
[skip circleci] |
| @@ -25,6 +26,26 @@ GHC versions not in the list have never been supported by HLS, or are not planne | |||
|
|
|||
| The policy for when we deprecate support for versions of GHC is given below. The table reflects that, but we may decide to deviate from it for good reasons. | |||
|
|
|||
| ### Support for the new GHC version | |||
There was a problem hiding this comment.
I think this belongs in Contributing. The intended audience of this page is users, and this isn't of interest to users, but rather to contributors who would go through this process.
There was a problem hiding this comment.
idk, the deprecation process described in this file, & the versioning information is here, so both support versions & deprecation of versions in this file, I thought it only logical to add an introduction of the new version here also to have the full GHC version lifecycle described in it.
I agree that I formulate it & present it as being useful for contributors. But that is one of agendas. (I imagine hypothetically) the majority of people who would search "why new version is not yet supported" - are users & hopefully would be directed to doc & would read the doc & majority of them would be satisfied with the answer that "it is complex, we working on it" & factually would not contribute, but some would get the cycle map & would try to contribute. And that is also why doc is formulated to encourage taking part in the activity.
There was a problem hiding this comment.
The deprecation policy is in here because we expect users to want to know "why is version X of GHC (which I care about) not supported".
the majority of people who would search "why new version is not yet supported" - are users & hopefully would be directed to doc & would read the doc & majority of them would be satisfied with the answer that "it is complex, we working on it"
That's not what this piece of documentation conveys, though! I think it would make sense to have a section here describing the basic policy for when new versions are included (e.g. "upstream tools and packages must support it, and some compatibility work must be done, here are links to the tracking tickets"), but a detailed checklist of steps belongs in the contributing documentation IMO.
There was a problem hiding this comment.
maybe the main content could go to contributing and link it here?
Anton-Latukha
changed the title
pepeiborra
added
the
status: unfinished
ghcupneeds to support new GHC, before HLS starts the support cycle).P.S.
In the documentation, I tend to practice less review & more use of active rewriting paradigm. And so when I am on the contributors side doing documentation - I can allow the workflow & want to practice what I preach, so call upon that workflow idea on myself. That means the branch is open to crowdsource document changes. Active reformulation & changes are appreciated. Reviews I would address in normal fashion.
Closes #2545.