On 2016-06-09 at 19:43:42 +0200, David Fox wrote:
or even worse silent failures where the code behaves subtly wrong or different than expected. Testsuites mitigate this to some degree, but they too are an imperfect solution to this hard problem.
It seems to me that if you have any thought at all for your library's clients the chances of this happening are pretty insignificant.
This is a common argument, and requires for APIs to avoid changing the semantics of existing operations in the API in a non-backward compatible way. And instead of modifying existing APIs/operations if this can't be done, introduce new operations ( foo, fooV2, fooV3, ...), effectively versioning at the function-level. If we did this consequently, we wouldn't need the PVP to provide us a semantic contract, as upper bounds would only ever be needed/added if somebody broke that eternal compatibility contract. A variation would be to only allow to change the semantics of existing symbols if the type-signature changes in a significant way, and thereby indexing/versioning the semantics by type-signatures rather than a numeric API version. In both cases, we also could dispose of the PVP, as then we could use the API signature as the contract predicting API compatibility (c.f. Backpack) In the former case, we could get away with lower bounds only, and since *the raison d'être of the PVP is predicting upper version bounds*, again, there would be no reason to follow the PVP anymore. The PVP is there so I have the means to communicate semantic changes to my libraries' clients in the first place. So while I don't usually deliberately break the API for fun, when I do, I perform using a major version increment to communicate this to my clients. In other words, I promise to do my best not to break my library's API until the next major version bump, and to signal API additions via minor version increments. That's the gist of the PVP contract. In addition to version numbers for the cabal meta-data & solver, I typically also provide a Changelog for humans to read, which (at the very least) describes the reasons for minor & major version increments. If clients of my library choose to deliberately ignore the contract I'm promising to uphold to the best of my abilities (by e.g. leaving off upper bounds), then it's flat-out the client library's author fault that code breaks for disrespecting the PVP. Certainly not mine, as *I* did follow the rules.