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

[Bryan O'Sullivan]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120815/38975a9a/attachment.htm>