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

[Lorenzo Bolla]

I definitely agree!
http://www.reddit.com/r/haskell/comments/x4knd/what_is_the_reason_for_haskells_cabal_package/

L.


On Wed, Aug 15, 2012 at 12:38:33PM -0700, Bryan O'Sullivan 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


-- 
Lorenzo Bolla
http://lbolla.info