qualified imports, PVP and so on

[Michael Snoyman]

On Wed, Feb 26, 2014 at 1:58 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Wed, Feb 26, 2014 at 10:37 AM, Michael Snoyman <michael at snoyman.com>wrote:
>
>> On Wed, Feb 26, 2014 at 11:17 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
>>
>>>  * What was the user's dependency range for monad-logger? If he is using
>>> the IO instance of MonadLogger from monad-logger, he ought to have a
>>> monad-logger == 2.0.* dependency (since removing instances require a major
>>> version bump.)
>>>
>>
>> The user didn't directly depend on monad-logger at all, as there was no
>> need with version 0.2 of monad-logger.
>>
>
> I guess the reason didn't have to depend directly on monad-logger was
> because he/she never mentioned any types from that package by name and thus
> didn't require an import of monad-logger modules.
>
> I wonder if we should have the PVP require that if a type you export in
> your API loses a class instance, then you're required to bump the major
> version number. This would have helped in this case.
>

In this case, that change would not have helped at all: the type which lost
an instance as IO, which was not exported by persistent (or monad-logger,
for that matter). MonadLogger *also* wasn't exported by persistent.

But I don't like this approach to the problem anyway. The theory seems to
be that, if we just keep "improving" the PVP, and make library authors'
lives more difficult, eventually we'll address all issues. Dependency
freezing is a complete solution to the problem described here, I don't
understand why there seems to be so much resistance to it.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140226/e5c29e3c/attachment.html>