[Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
michael at snoyman.com
Thu Aug 16 07:01:55 CEST 2012
On Thu, Aug 16, 2012 at 5:38 AM, Conrad Parker <conrad at metadecks.org> wrote:
> 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
> > point, as the number of projects on Hackage that are intended to hack
> > the problem slowly grows.
> > I am currently undergoing a fresh visit to that unhappy realm, as I try
> > 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
> > 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.
In general, I've been taking the approach recently that we have two classes
of packages: some (like transformers and bytestring) have mostly-stable
APIs, and most code I write only relies on those APIs. If I'm just using
Data.ByteString for the ByteString type and a few functions like readFile
and map, it's highly unlikely that the next version will introduce some
breaking change. In those cases, I've been leaving off the upper bound
For other packages that haven't yet stabilized, I've still been keeping the
upper bound. In many cases, even that isn't necessary. I've tried removing
the upper bounds on those as well, but I almost always end up getting
someone filing a bug report that I left off some upper bound and therefore
a compile failed.
I agree with Bryan's argument, but I'd like to keep consistency for most
packages on Hackage. If the community goes in this direction, I'll go along
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe