On 16 August 2012 03:38, 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.
Likewise ...
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):
I think part of the problem might be that some packages (like bytestring, transformers?) have had their major version number incremented even despite being backwards-compatible. Perhaps there are incompatible changes, but most of the cabal churn I've seen recently has involved incrementing the bytestring upper bound to <0.11 without requiring any code changes to modules using Data.ByteString. IMO it'd be better to include a separate versioning entry like libtool's version-info, consisting of Current:Revision:Age (http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.h...), and leave the published "version" for human, marketing purposes. I remember discussing this with Duncan at ICFP last year, and he suggested that the existing PVP is equivalent to the libtool scheme in that the major release should only be incremented if backwards-compatibility breaks. However I think people also expect to use the published version as a kind of marketing, to indicate that the project has reached some milestone or stability, or is part of some larger, separately versioned group of packages (eg. new compiler or platform release). The PVP pretty much ensures that incrementing a major version for such reasons is going to break your package for all its users. Conrad.