Spurred by the discussion in How much effort does backwards compatibility require from library authors?, I wrote up some thoughts about my GHC support policy.
For the six years that I ran the Haskell survey, the three latest major versions of GHC covered the vast majority of the community (2022, 2021, 2020, 2019, 2018, 2017).
I think there are good reasons to suspect that that is no longer the case. In particular, ghcup still recommends and defaults to 9.4.8. Furthermore, I still see a lot of people (especially beginners) report errors without error codes, which means they must be on pre 9.8 versions.
1 Like
Also note that the next recommended GHC version in GHCup will be 9.6.7.
And that 9.12.1 is busted: [PSA]: Correctness issue in GHC-9.12
So right now, you’re effectively only supporting two valid versions of GHC.
6 Likes
I wonder if beginner users are accurately reflected in the surveys. I wouldn’t be surprised if they are more likely to use older versions (eg, a version installed on their university lab’s computer) and are less likely to fill out the survey. I imagine the type of person who fills out the survey is more actively engaged with Haskell, and more likely to upgrade regularly.
6 Likes
Out of interest, do you have a list of issues blocking 9.8 or 9.10 from becoming the recommended version?
No, but 9.6.7 will be a strong engineering release with lots of backports. I don’t see a reason to bump it to 9.8 or 9.10 in the light of it.
5 Likes
Yes. I think I wasn’t even aware there were surveys going on, because I don’t hang out where it was advertised. But anyway
For the six years that I ran the Haskell survey, the three latest major versions of GHC covered the vast majority of the community.
As of the 2022 survey, 41% reported still using 8.10. A “vast” minority? (But the %ages add up to well more than 100, so I’m not seeing what evidence this is.)
Perhaps a line of questions if we run another survey is: do you deliberately download outdated versions of packages, to correspond with the GHC version you’re using?/would you if available?/are you aware that’s possible?
On the substantive topic [**], I appreciate everybody who contributes packages to the community. It’s a bonus if they maintain them. I don’t expect them to actively maintain outdated versions. (A note of bugs discovered in newer versions but known to also afflict an older version won'tfix would be a kindness.)
[**] Addit: I see taylorfausak’s packages don’t tickle my interests particularly, so I’m not in the demographic that might have an opinion on this particular Support Policy.
(Nice to see in flow an attempt to free us from the chains of dot-as-compose.)
I suspect the vast majority of cabal/stack users do that at times by default.
“outdated” feels more like “software compatible with my GHC installation”, which is most of the times perfectly fine.
3 Likes
Hehe! I joined Discourse only in late 2021 – and possibly because I’d missed out on those sort of notifications. I see in that search, there’s 2019 complaints even Discourse wasn’t included in possible answers. IIRC the first few surveys were notified only on reddit.
This seems relevant “not seen an announcement on the mailing lists”.
Since the original doubts were wrt beginners, where do they hang out? Are they in the target demographics for taylorfausak’s packages?
Regarding my GHC musl Dev Containers:
- GHC 9.12 (latest)
- GHC 9.12.2 + cabal-install 3.14.1.1 + Stack 3.5.1 + HLS 2.10.0.0
- GHC 9.10
- GHC 9.10.1 + cabal-install 3.12.1.0 + Stack 3.5.1 + HLS 2.10.0.0
- GHC 9.8
- GHC 9.8.4 + cabal-install 3.10.3.0 + Stack 3.5.1 + HLS 2.10.0.0
- GHC 9.6 (recommended)
- GHC 9.6.7 + cabal-install 3.10.3.0 + Stack 3.1.1 + HLS 2.10.0.0
I promoted GHC 9.6[.5] to recommended when GHC 9.10.1 came out.
My policy is to support the three latest major versions of GHC plus the recommended version – which may be out of sync with Installation - GHCup.