PVP bounds on core libraries during development
Hi. To illustrate - There was a modification to template-haskell a few days ago that was what would have been a PVP change that was subsequently reverted:
Specifics aside, horizon actually caught this incompatibility during the short time it was broken:
https://gitlab.horizon-haskell.net/package-sets/horizon-core/-/jobs/240966
My next step would have been to preprocess th-abstraction properly against the correct version of template-haskell, which would have been 2,21,0 - however, the version was not moved along with this change, so any modification to the downstream library would have been a temporary and incorrect fix.
My questions are: Is it possible to respect PVP during development so that future proofing work can be done somewhat reliably downstream, in light of the fact that a reversion may also revert versioning? Is it more correct to say that the PVP should change continuously to reflect the state of the code as is, rather than changing it at some arbitrary point near release - OR - Is it more correct to say that that unreleased versions of a library should, for all intents and purposes, not exist for downstream users? There seem to be pros and cons in either scenario, but the choice here changes the strategy to future proofing code ahead of release.
As another example, here is a simpler case that I think is a PVP change to template-haskell in mainline at the moment (should read 2,21,0):
https://github.com/locallycompact/dhall-haskell/commit/a74c8dc9ced7ce578664b1e89401116ff96b5e64