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

[Carter Schonwald]

This thread is kinda missing an important point.

Namely that on hackage now, the admins and trustees have the power to edit
the cabal files to fix broken constraints. (As do maintainers of their own
packages)

Whether relaxing incorrectly conservative or over strengthening overly lax
constraints, this now doesn't require a rerelease to "fix".  There are
valid reasons of provinence for why that might not make sense in all case

Unless I'm missing the point, doesn't that solve most of the matter?
-carter

On Tuesday, February 25, 2014, Michael Snoyman <michael at snoyman.com> wrote:

>
>
>
> On Tue, Feb 25, 2014 at 5:12 PM, Brandon Allbery <allbery.b at gmail.com<javascript:_e(%7B%7D,'cvml','allbery.b at gmail.com');>
> > wrote:
>
>> On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman <michael at snoyman.com<javascript:_e(%7B%7D,'cvml','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.
>>
>>
> I think it's a false dichotomy. I've received plenty of complaints from
> users about being unable to install newer versions of some dependency
> because a library that Yesod depends on has an unnecessary strict upper
> bound. Are there situations where the PVP saves a user some pain? Yes. Are
> there situations where the PVP causes a user some pain? Yes.
>
> It's disingenuous to frame this as a black and white "developer vs user"
> issue, it's far more complex than that. After a lot of experience, I
> believe the PVP- or at least strict adherence to it- is a net loss.
>
> And I think the *real* solution is something like Stackage, where curators
> have taken care of the versioning pain points instead of either developers
> or end users. Linux distributions have been doing this for a long time.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140225/ab5fcdf0/attachment-0001.html>