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

[Twan van Laarhoven]

On 25/02/14 16:12, Brandon Allbery wrote:
> On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman <michael at snoyman.com
> <mailto: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.

Strict upper bounds are horrible when a new version of, say, the base library 
comes out. In reality 90% of the code will not break, it will just require a new 
release with increased version bounds. These upper bounds actually *hurt* users, 
because they suddenly couldn't use half of Hackage.

This reminds me of the situation of Firefox extensions. In earlier versions of 
the browser these came with strict upper bounds, saying "I work in Firefox 11 up 
to 13". But then every month or so when a new version came out, all extensions 
would stop working. Newer versions of the browser have switched to an 'assume it 
works' model, where problems are reported and only then will the extension be 
disabled.

So, violating upper-bounds should be a warning at most, perhaps for some kind of 
loose 'tested-with' upper bound. Additionally, we need a way to report build 
successes and failures to Hackage, and automatically update these 'tested-with' 
upper bounds.

In other words, make a distinction between upper bounds violations that mean 
"not known to work with versions >X" and "known not to work with versions >X".


Twan