How much effort does backwards compatibility require from library authors?

[tomjaguarpaw]

@tomjaguarpaw

As far as I know if you use a particular Stackage snapshot you can’t upgrade whatever separately from the whole snapshot itself – but I don’t use Stack or Stackage, so maybe I’ve got the wrong idea.

@chrisdone

since about 2017 it’s been really trivial to add a so-called extra-dep to your stack.yaml file which essentially exists to use a newer or modified version of any given package

With the continued caveat of “I don’t use Stack so I’m not talking from personal experience and may have got a completely wrong impression”, here is a recent example of the kind of thing I see that led me to believe that Stack/Stackage has trouble upgrading dependencies individually:

Unable to get hls to work while having lens and random as dependencies

I came back to a project I haven’t worked on for a year, using VS Code and stack. The goal is to get HLS to run. I was using the ghc-9.6.3 resolver. At some point, I did a “stack clean.” After that I couldn’t build my project. Stack said that lens depended on other libraries and that no version of those libraries was in the build plan. I switched to the lts-23.18 resolver and the project built fine, but now HLS says that it doesn’t support ghc 9.8.4. ghcup reports that ghc-9.8.1 is HLS-powered. …