Should the PVP be changed with regards to instances?

[Bardur Arantsson]

Jeremy Shaw wrote:

> On Wed, Dec 21, 2011 at 11:24 AM, wren ng thornton <wren at freegeek.org>
> 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.
> 
[--snip--]

> 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?)

[--snip--]

> 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 
management.

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.