It recently occurred to me that we could have --pvp-bounds use broader constraints, by having it take into account multiple stackage snapshots. The simplest cut at this would be a funky field like other-resolvers: [lts-2.0, lts-3.19]. This would broaden the constraints placed on dependencies, to include the versions in both snapshots.

Ideally, this feature would be implemented such that these configurations actually build and pass tests. I think this can be done by having sdist and upload support building and testing the tarballs against all configurations (#717).

Since you might need a different set of extra-deps for a given resolver, we really need to have multiple project configurations. I can think of two ways to do this:

• Support multiple configurations in one file, as requested in Feature request : multiple build configurations #392. In Using environment variables in stack.yaml #1375 , avoiding complications of the stack.yaml format is discussed.
• Use multiple stack.yaml files when running sdist. I don't like this because it'd be easy to forget to specify the additional files, and we can't just slurp in all the *.yaml files.

With configuration inheritance, I bet just overriding the resolver would work for many people's usages. So, I'm beginning to lean towards doing something like that. I don't think it'd be all that complicated (it's already a monoid, we're already using inheritance for the non-project options), and it's useful for other reasons.

I think this is a very principled way of setting your version constraint bounds: pick the extremes of the snapshots that you want to support, and perhaps even a few in the middle. Then, actually test that these snapshots work. This does not guarantee that all the versions in the middle will work, it's likely that they will. For the exceptional cases where this doesn't hold, the user can put fancier version constraints into the cabal files, which won't get overridden.

Side note: Another thing to consider is whether this should support inplace modification of cabal files. I think it's weird that we can end up in a situation where the repo's cabal file doesn't have constraints, whereas the hackage package does. However, implementing this shouldn't be blocked on that - refactoring cabal files seems tricky.