Re: The PVP ought to mention dependency bounds (Was: Growing Haskell Platform)

On Fri, Dec 7, 2012 at 6:20 PM, Johan Tibell wrote:

On Thu, Dec 6, 2012 at 11:52 PM, Michael Snoyman wrote:

...

I thought the natural response to this would be to put a lower bound on text. After all, following the PVP, there should be no problem with updating a minor version number. However, when I did so, many users of the Haskell Platform were no longer able to compile due to conflicting dependencies. The result: I had to put in some dirty conditional compilation tricks in persistent to avoid inlining `pack` when using older versions of text.

I've meant to write about this but haven't yet found time to do so.

Assuming that the goal of the PVP is to make sure that a packages that previously compiled continues to compile, dependencies must be taken into account when computing package version number bumps. For example, given these packages:

A-1.0 B-1.0 depends on A-1.0.0.* C-1.0 depends on A-1.0.0.* and B-1.0.0.*

Now assume that A-2.0 is released and B starts depending on the new version of A (without changing its own API). He now have this situation:

A-1.0 A-2.0 B-1.?.?.? depends on A-2.0.0.* C-1.0 depends on A-1.0.0.* and B-1.0.0.*

If B only bumps its patch-level version (i.e. to B-1.0.0.1), C no longer compiles (due to a version constraint failure) with B-1.0.0.1 even though C's dependency on B (i.e. B-1.0.0.*) suggests that it would. If B updates it's lower bound on a dependency it must bump its own major version number.

We can summarize this under the slogan "versions are APIs"; the versions you depend on are part of your API.

Aside: Even if cabal install would backtrack and *not* use the new version of B (i.e. B-1.0.0.1) and thus be able to compile C-1.0 using the old version of B things would still be bad as C's dependency constraints would be a lie.

I think the PVP policy must be changed to require that increasing lower bounds on dependencies requires an increase in the major version number.

-- Johan

+1. I already try and follow this policy myself, I've seen the lack of clarity on it lead to versioning problems in the past. If anyone is interested, I can try to dredge up the actual incidents. Michael