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

[Conrad Parker]

On 16 August 2012 03:38, 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.

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.html),
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.