Should the PVP be changed with regards to instances?

Bardur Arantsson spam at
Wed Dec 21 19:10:56 CET 2011

Jeremy Shaw wrote:

> On Wed, Dec 21, 2011 at 11:24 AM, wren ng thornton <wren at>
> wrote:
>> Agreed with this. And with Ganesh Sittampalam: the solution to the
>> problem of major version changes is automated testing/reporting, not
>> allowing potentially breaking changes in minor versions.

> Let's say the authors of text add a new instance[1]. I can not
> actually update to that new version of text until all the other
> libraries I use that depend on it are updated. For a very popular
> library, like text, than can take awhile. So, I am stuck with the old
> version until everybody updates -- and probably all they are going to
> do is bump the version range.

One of the major problems here, I find, is the fact that packages that your 
package depends on *but which are not part of the API to your package 
exposes to the world* lead to conflicts. (I this solvable currently? Perhaps 
one can create both an *-api package and a *-impl package?)


> Alternatively, a system where libraries exported some sort of
> declaration of the API they need, so that the PVP is irrelevant would
> be nice too -- if such a thing could be made to work. The core issue
> is, after all, that we basically have a single bit of information that
> we use to declare that the API is changed. That is obviously not very
> fine grained...

Separation of what the package API actually *is* versus what it uses 
internally would be extremely desirable. I usually find that it's actually 
"implementation" dependencies that get me into trouble with dependency 

I realize that it may not exactly be a trivial proposition to implement 
something like this, but AFAICT .cabal files actually contain enough 
information to (theoretically at least) be able to implement this.

More information about the Libraries mailing list