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

[Johan Tibell]

On Thu, Dec 6, 2012 at 11:52 PM, Michael Snoyman <michael at snoyman.com> 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