Why upper bound version numbers?

[Herbert Valerio Riedel]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160610/04ff8dda/attachment.sig>