[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

Erik Hesselink hesselink at gmail.com
Mon Aug 20 09:33:22 CEST 2012

I am strongly against this, especially for packages in the platform.

If you fail to specify an upper bound, and I depend on your package,
your dependencies can break my package! For example, say I develop
executable A and I depend on library B == 1.0. Library B depends on
library C >= 0.5 (no upper bound). Now C 0.6 is released, which is
incompatible with B. This suddenly breaks my build, even though I have
not changed anything about my code or dependencies. This goes against
the 'robust' aspect mentioned as one of the properties of the Haskell
platform, and against the Haskell philosophy of correctness in

This is not an imaginary problem. At my company, we've run into these
problems numerous times already. Since we also have people who are not
experts at Cabal and the Haskell ecosystem building our software, this
can be very annoying. The fix is also not trivial: we can add a
dependency on a package we don't use to all our executables or we can
fork the library (B, in the example above) and add an upper bound/fix
the code. Both add a lot of complexity that we don't want. Add to that
the build failures and associated emails from CI systems like Jenkins.

I can see the maintenance burder you have, since we have to do the
same for our code. But until some Cabal feature is added to ignore
upper bounds or specify soft upper bounds, please follow the PVP, also
in this regard. It helps us maintain a situation where only our own
actions can break our software.


On Wed, Aug 15, 2012 at 9:38 PM, Bryan O'Sullivan <bos at serpentine.com> wrote:
> Hi, folks -
> I'm sure we are all familiar with the phrase "cabal dependency hell" at this
> point, as the number of projects on Hackage that are intended to hack around
> the problem slowly grows.
> I am currently undergoing a fresh visit to that unhappy realm, as I try to
> rebuild some of my packages to see if they work with the GHC 7.6 release
> candidate.
> A substantial number of the difficulties I am encountering are related to
> packages specifying upper bounds on their dependencies. This is a recurrent
> problem, and its source lies in the recommendations of the PVP itself
> (problematic phrase highlighted in bold):
>> When publishing a Cabal package, you should ensure that your dependencies
>> in the build-depends field are accurate. This means specifying not only
>> lower bounds, but also upper bounds on every dependency.
> I understand that the intention behind requiring tight upper bounds was
> good, but in practice this has worked out terribly, leading to depsolver
> failures that prevent a package from being installed, when everything goes
> smoothly with the upper bounds relaxed. The default response has been for a
> flurry of small updates to packages in which the upper bounds are loosened,
> thus guaranteeing that the problem will recur in a year or less. This is
> neither sensible, fun, nor sustainable.
> In practice, when an author bumps a version of a depended-upon package, the
> changes are almost always either benign, or will lead to compilation failure
> in the depending-upon package. A benign change will obviously have no
> visible effect, while a compilation failure is actually better than a
> depsolver failure, because it's more informative.
> This leaves the nasty-but-in-my-experience-rare case of runtime failures
> caused by semantic changes. In these instances, a downstream package should
> reactively add an upper bound once a problem is discovered.
> I propose that the sense of the recommendation around upper bounds in the
> PVP be reversed: upper bounds should be specified only when there is a known
> problem with a new version of a depended-upon package.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list