ghc support deprecation schedule #2168
Comments
|
I'd suggest to support at most 2 GHC versions in a X.Y branch. So |
That would be the general criteria but i am afraid that 8.10.6 was a somewhat failed 8.10.7 so i think it worths to keep 8.10.5 a little bit but give users some more time to jump from 8.10.6 to 8.10.7 |
|
Thanks to @maralorn's question in matrix it worths to note that |
|
I would be against dropping 8.8 support if we landed "full 9.2 support" tomorrow. One way to encode my reservation would be including "Stackage Nightly" or even "Stackage LTS" as a condition for "full support". I.e. a GHC version is not considered mature until it has full support from HLS and from Stackage |
|
totally agree, updated the issue description |
I agree. That's why I think it's more worthwhile to support many X.Y versions, but as few X.Y.Z combinations. Industry users may have several reasons to lack behind significantly. However, updating from 8.10.5 to 8.10.7 is little to no effort, since base/core libs are usually PVP compatible.
I don't think HLS needs a notion of "mature GHC" even. And cabal users may disagree what mature means. But we need a notion of "legacy". |
The current version of HLS doesn't support anything after 8.10.5. If HLS's next release dropped support for GHC 8.10.5, there would be no way to upgrade HLS without simultaneously upgrading GHC. That's really bad user support. |
Good point. I think given all the information in this thread we could easily write a simple policy anyone doing a release can follow. |
|
I am currently working on getting HLS working in a (work) setting that's still using GHC 8.6.5. It would be disappointing if I finished this project, only to have it become harder to install HLS for 8.6.5. I take some consolation in the fact that older versions of HLS would still be available. If software like the VSCode Haskell extension could be aware of this and be willing to install those older versions without pulling teeth, that would be even better. |
|
I know that it causes a lot of maintenance issues to have all those versions, but I'm also against dropping GHC 8.6.5. It is quite a well-working version in many systems, and I often meet (industrial, non-public) projects using GHC 8.6.5, not later, for exactly that reason. I think we should support at least the latest version for each X.Y version until really most of the ppl (like < 0.5% or so) (based on Haskell survey or something) move to some other minor versions or something. |
I am with you, i know 8.6.5 is a beloved version and myself, as a windows user, have been using it for a long time cause it was the unique reliable ghc version in windows, until 8.10.5 arrived. But hls relies heavily in features added in ghc-8.8 (hie files), we have to maintain an entire package to get compat with 8.6.5 (hie-compat). At some point we will no able to leverage new ghc features cause making it compatibles will not be possible (or not feasible/reliable given our resources).
That is a really good idea, not sure if other installation tools (ghcup?) could be improved for that
Mmm, i like to be conservative with deprecations, but maybe that requirement is too hard imo, given users could continue using old versions of hls. Well the ghc team itself is not maintaining those versions and users continue using them, without new bug fixes or features. What about move version deprecation and keep 8.6.5 until 9.2.* is widely used? |
|
If an industrial user is still on 8.6.5 after we drop support, they should be happy to stick to an old version. After all, they already stick to old versions of all the packages they use and have decided that this is preferable (cost-wise) than upgrading their compiler. So I don't think we should encumber our most important cohort (OSS contributors and maintainers) with a slower deprecation schedule for the benefit of organisations who have already decided that sticking to older versions is fine. Summarising the contents of this thread that have wider agreement:
|
I would say that it could be one too (to keep only 8.6.5 and 8.8.4 at some point) |
I mean, ghcup already allows to install multiple HLS versions side-by-side. If you have a legacy project that needs ghc 8.6.5, just keep an older HLS installed and switch to it via There are two things that could be improved:
|
Sorry to complicate this a little more, but I'd say:
So, if 8.10.8 and 9.0.2 was released tomorrow, we'd support: Additionally, we should make it easier to compile HLS from source against your choice of GHC. There are some shenanigans that need solving, also see #2092 (comment) |
I think this schedule will be better than dropping just after full support. We should deal with early adopters but also most of Haskell users, IMO.
The fact that they stick with the older compiler does not mean that they want worse development experience. In fact, GHC 8.6.5 is, IMO, preferred because of the opposite reason. GHC 8.8 sometimes malfunctions in Windows, GHC 8.10 experiences issues in Mac. So I believe they chose GHC 8.6 to have a better (and consistent) DX. |
|
At this point we don‘t have full hls support for 9.0.1 let alone 9.2.x. I agree very much with @pepeiborra that developer time is our most precious resource, and supporting many ghc versions is a huge burden.
I don‘t think that using a stable and tested hls version with your stable and tested ghc version is a bad developer experience. Otoh if hls development is constrained too much by supporting a large number of ghc versions, overall development experience will suffer for everyone in the long run. I think we should strive for at least one stable release of hls for every ghc version. And it should be really easy to install a working hls for every ghc version out there. In the worst case we can even branch-off and do critical bug fix releases for older hls versions. Seeing that different ghc versions life in different branches of ghc, maintaining different ghc versions in different branches of hls might actually be less work. There is one counter argument I see: If there are hls developers who are constraint to use old versions of ghc e.g. in their day job, I can see how dropping support for that ghc version would be very detrimental to motivation. I assume implementing a feature that you can only use in a year or so is probably pretty annoying. I have no idea how much that would be the case, though. |
As I said, not the HLS usage itself but the compilers have some issues with OSs, which can cause DX issues. Moreover, I'm not suggesting that we should preserve all GHC versions forever. I'm just arguing that, for some specific stable version like 8.6.5, it's possible to be worth the effort at least for a while. |
|
To clarify my earlier comments about 8.6.5, I think it's the overall user experience that matters. There are several ways one can get a HLS install. One way is just to run VSCode and install the Haskell extension from within VSCode. I'm not sure where HLS comes from in that situation. There may or may not be equivalents for other editors. Another is to install manually with ghcup. I suspect most users get HLS in one of those two way rather than building from source. If those two ways of getting HLS make it easy to obtain old HLS versions as needed, then I'm not concerned with whether the HLS project continues support in new versions. I know that ghcup does make it easy enough. I don't know about the HLS that's obtained by installing the VSCode extension, or of there are equivalents for other editors. Does anyone know these details? Checking a running install of VSCode, the server is installed into |
|
@cdsmith As far as I know, the VSCode extension is the only extension that supports the auto-installation of HLS, and it installs the latest GitHub release of HLS. |
|
I'm looking through the configuration now, and one can install a different HLS and configure VSCode to use it instead. It's a bit hidden, but with enough user education, it could be an option. Still, not a step to be taken lightly. I now know how to get around dropping support, but I suspect a lot of the users affected, especially those who are using Haskell in their companies but not participating in the broader community, will be lost by this change. :( |
|
@cdsmith Is that a problem that could be solved on the VSCode extension side? Can VSCode install different (prebuilt?) versions of HLS based on which version of a compiler a Haskell project is using? I've never tried setting up anything like that, so I don't know whether it's practical. |
I am afraid that the extension goes for the last version by default as a whole. If you had already installed the previous version it will continue using it but no if you start with a fresh cache. So we could teach the extension the matrix of ghc versions -> hls versions and download the appropiate one. It is doable though and it could serve for ohter purposes as improve error messages when a ghc version is not supported at all: haskell/vscode-haskell#453 The extansion will honour the set of hls+ghc versions in PATH so you always could do it "manually", or set explicitly the path to hls per project. But ideally the extension should do it auto. |
opened issue about in the extension issue tracker haskell/vscode-haskell#454 |
what do you think about this @pepeiborra? i aim to write down the proposal based in your comment: #2168 (comment) |
|
Sounds good to me |
|
@cdsmith would your concerns being adressed with
(it would drop 8.6.5 when 9.2 will be in a stackage lts) and (to continue giving support for 8.6 auto in the vscode extension) |
This makes me sad. I already feel now that you'll dismiss me because I'm working for a company writing Haskell (for all of two weeks now), but I've been a part of the Haskell community working on open source projects for 10 years longer than that, and really wish people would give each other the benefit of the doubt and feel we're on the same team. Several companies using Haskell are pulling far more than their own weight when it comes to contributions to the community. Apparently not everyone thinks it's enough, and I suppose people are entitled to their opinions, but this kind of hostility between parts of the community is really heartbreaking to me. |
It's also completely unwarranted since you had twice before in this thread said that you explicitly don't expect all the newest features for older ghc versions. So I hope this is more of a misunderstanding. Also in this specific case I am not sure how money could easily help. |
|
@cdsmith sorry it was dismissive, not my intention! I just have seen this in a lot of spaces (wanting older compiler support for tooling/libraries/etc specifically for industrial use) and I think industrial users should provide resources (in whatever form is appropriate) to make their wishes a higher priority. |
Ailrun
added
the
status: in discussion
Fair enough, and apologies if I overreacted. Please understand these comments, at least if I make them, as just a note that there are likely to be a lot of users still on 8.6.5 even if it doesn't look like it from all points of view. They are not intended to cast industry users as any more (or less) important than other users. |
@pepeiborra toughts on that last ammend? |
|
Honestly, I don't like the idea of inaugurating a ghc deprecation policy with an exception. And I don't see the need for it either. The policy is not automated - 8.6.5 support won't be going away until someone actively removes it, which is unlikely to happen the day after - the policy simply states that it's ok to remove it. |
|
I agree with @pepeiborra A policy is a policy, not a law. It aids in decision making. Exceptions don't need to be covered by it. |
|
Just for reference these are the versions of ghc in some current Linux distro releases: Arch: 8.10.5 |
many thanks, however problematic releases usually has problems in windows and/or mac (coincidence?? dont believe so! 😛) :
so use 8.6.5 had make more sense in windows |
|
The official Haskell container on docker hub is still at 8.10.4 and I would love to upgrade to 8.10.7 but I'm stuck there. https://hub.docker.com/_/haskell?tab=tags&page=1&ordering=last_updated |
|
I would also suggest delaying 8.10.4 deprecation a little longer: it was a rather long lived minor release, corresponding to lts17. Also just to clarify my previous comment: I just wanted to list the Linux distros to show that distros do lag (also in minor versions) and some may never even adopt 8.10.7 say but instead eventually jump straight to 9.0.x I image: from the Linux PoV there is almost no difference between 8.10.5 and 8.10.7. It was not to suggest dropping 8.6.5 support. :-) Also I think there is a fair chance we may see LTS 19 released for ghc-9.0 by the end of this year. |
Why? Updating to 8.10.7 can be reasonably expected of users with no change in dependency configuration. It's also supported by stackage.
There are many ways to install 8.10.7 on Linux distros. I don't see an issue here. |
I am afraid we (i) just removed it, i hope upgrading to lts 18 willnot be problematic
Sorry for misunderstand your intent, now i see your point and agree with it, so we should take that versions in account before make a decision. Fortunately we keep support for ghc-8.10.5 for other reasons so i hope actual version list would be fine from that pov. Sure there would be linux users, maybe occasional ones, who dont want to worry about installing new ghc versions and want to use the included one in their distro. Although upgrading nowadays is really easy thanks to ghcup. |
how, if the official docker is still at 8.10.4. There is a discussion going on here about the docker container: And Stackage is still in nightly for GHC 9.0.1. |
At least it would suppose we are not gonna trigger the deprecation for 9.0.1, as we will wait until 9.0.1 is in stackage |
if I understand this correctly that VSCode will just automatically use the old HLS for ghc 8.10.4 then I withdraw all objections |
Just curious... why are you locked to the official docker image? |
Using a "blessed" image makes it more likely that it's stable. But again, if HLS still works for the old version, but doesn't have the newest features, then that totally works for me. |
That what is stable? I'd recommend just using a stock Docker image and install GHC/cabal inside instead of downloading 2-3 GB. It's also faster in my experience. I've never used the "haskell" docker images.
You can install 8.10.7 just fine on debian. |
|
As a tangent to all this discussion, can I suggest we capture the output of this in a version support table in the docs, alongside the policy? |
Yeah as commented above I want to write down the policy somewhere in docs. |
|
Opened pr with the proposal: #2231 |
|
We have a document describing the ghc deprecation policy and a schedule/history of ghc versions support: I hope it included at some degree all point of viewes and considerations made here, very much thanks all for participating in the discussion. |
hie-compat//cc @pepeiborra @Ailrun @ndmitchell @mpickering @wz1000 @berberman @isovector @hasufell
The text was updated successfully, but these errors were encountered: