qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method)

[Brandon Allbery]

On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman <michael at snoyman.com>wrote:

> But that's only one half of the "package interoperability" issue. I face
> this first hand on a daily basis with my Stackage maintenance. I spend far
> more time reporting issues of restrictive upper bounds than I do with
> broken builds from upstream changes. So I look at this as purely a game of
> statistics: are you more likely to have code break because version 1.2 of
> text changes the type of the map function and you didn't have an upper
> bound, or because two dependencies of yours have *conflicting* versions
> bounds on a package like aeson[2]? In my experience, the latter occurs far
> more often than the former.


I have a question for you.

Is it better to save a developer some work, or is it better to force that
work onto end users?

Because we keep constantly seeing examples where saving the developer some
upper bounds PVP work forces users to deal with unexpected errors, but
since Haskell developers don't see that user pain it is considered
irrelevant/nonexistent and certainly not any justification for saving
developers some work.

Personally, I think any ecosystem which strongly prefers pushing versioning
pain points onto end users instead of developers is doing itself a severe
disservice.

Are there things that could be improved about versioning policy?
Absolutely. But pushing problems onto end users is not an improvement.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140225/acb2bc67/attachment.html>