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

Michael Snoyman michael at
Sat Dec 8 20:48:46 CET 2012

On Fri, Dec 7, 2012 at 6:20 PM, Johan Tibell <johan.tibell at> wrote:

> On Thu, Dec 6, 2012 at 11:52 PM, Michael Snoyman <michael at>
> 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-, C no
> longer compiles (due to a version constraint failure) with B-
> 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- 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list