Dependency version bounds are a lie

[chrisdone]

@hasufell

However, at least on package level (not module level), I believe you can execute this policy within PVP realm. Instead of copying the entire package, you just bump the major version […]

This is the major issue with how PVP is lived today: no one bothers maintaining multiple major versions.

Problems:

1. Cabal disallows two versions of the same library being used in the same project. Related is the “diamond dependency problem.”
2. Having to choose a single version of a package means all your package versions have to move in lock-step. That creates churn, and it’s not your choice to update a package, rather, some other package wants it.
3. There’s no path to let end users create migration code from the old version to the new version.
4. Stackage and Nix don’t presently support testing two versions of a package within one package set.

Slapping a major version on it doesn’t help. Making a new package namespace called package2 avoids all these problems.

[NicolasT]

No, not caused by your tool Just wanted to point out an issue I ran into which others might run into as well, in a specific situation. Basically, when having multiple packages in a single repo, where package A has a build-depends on some older version (or compatible) of B, then testing against the lower bound of B requires some messing with cabal.project in CI, otherwise the solver will only accept the version of B as found in the repository, which won’t match with the desired lower bound version.