From people i follow on Github i noticed a few pull requests that introduce support for the GHC version 9.12 but drop support for older (but not that old) GHC versions like 9.6, e.g. Add support for GHC 9.12, drop support for GHC 9.6 by tfausak · Pull Request #118 · tfausak/witch · GitHub and Drop s…

I’d like to comment from a different user perspective: Thank you library maintainers, for giving me the option to use a recent GHC in a timely manner! The situation is so much better than a few years ago. I don’t care about have an issue with using slightly older packages or trying to allow newer …

[image] taylorfausak: This is how I’ve chosen to maintain my packages. I have my reasons, but it sounds like they don’t resonate with you. That’s fine. Naturally, you’re welcome to maintain your packages however you want for any reason or no reason at all. Sorry if you’ve already shared and I…

For me it’s not about any particular version of GHC. Sometimes it would not require much to maintain support, other times it would require a lot. I would prefer to have a policy that is easy to reason about (“latest three major versions”) rather than one that might have more supported configurations…

I keep a stable API for my packages, but I don’t give any thought to backwards compatibility wrt. GHC. Forwards compatibility tends to come for free by users of the package who are excited about the newest GHC out in the form of a PR. Amount of work for me is close to zero. My assumption is that, l…

Thanks for the responses. So far the discussion mostly evolved around “latest three major versions” policy. I’m very interested to read the rationale for it at some point, because my speculation would be that it’s a valid and pragmatic choice to reduce maintenance overhead (code, ci, discussions et…

[image] malteneuss: So far the discussion mostly evolved around “latest three major versions” policy. I’m very interested to read the rationale for it at some point Three major GHC versions cover the latest bleeding edge one, the one used by Stackage Nightly and the one used by Stackage LTS. …

Evidently nixpkgs is stuck on 9.6 due to “significant breakage”. It seems close though: haskellPackages: Stackage LTS 22 -> 23; ghc: 9.6.6 -> 9.8.4 by sternenseemann · Pull Request #371032 · NixOS/nixpkgs · GitHub .

What is the drawback of dropping support early? Once you drop supporting a GHC version in your library, you can no longer serve bug-fixes (nor new features) to the users of your library that are on this GHC version. For that reason, my approach is conservative: Atm, I am dropping support for GHC…

Thanks for explaining this in detail. This is basically my approach. Whereas Taylor says [image] taylorfausak: I would prefer to have a policy that is easy to reason about (“latest three major versions”) rather than one that might have more supported configurations somewhat randomly (“whatever …

How much effort does backwards compatibility require from library authors?

Learn

taylorfausak March 12, 2025, 2:10am 21