Hi Michael,

On Wed, Feb 26, 2014 at 6:45 AM, Michael Snoyman <michael@snoyman.com> wrote:

That's essentially it. I'll give one of the examples I ran into. (Names omitted on purpose, if the involved party wants to identify himself, please do so, I just didn't feel comfortable doing so without your permission.) Version 0.2 of monad-logger included MonadLogger instances for IO and other base monads. For various reasons, these were removed, and the version bumped to 0.3. This is in full compliance with the PVP.

persistent depends on monad-logger. It can work with either version 0.2 or 0.3 of monad-logger, and the cabal file allows this via `monad-logger >= 0.2 && < 0.4` (or something like that). Again, full PVP compliance.

A user wrote code against persistent when monad-logger version 0.2 was available. He used a function that looked like:

runDatabase :: MonadLogger m => Persistent a -> m a

(highly simplified). In his application, he used this in the IO monad. He depended on persistent with proper lower and upper bounds. Once again, full PVP compliance.

Once I released version 0.3 of monad-logger, his next build automatically upgraded him to monad-logger 0.3, and suddenly his code broke, because there's no MonadLogger instance for IO.

Now *if* the program had been using a system like "cabal freeze" or the like, this could have never happened: cabal wouldn't be trying to automatically upgrade to monad-logger 0.3.

I'm trying to wrap my head around this.

 * Is runDatabase above a function in persistent or related packages or a function that the user 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.)

 * Does any involved package use orphan instances?