Re: Should the PVP be changed with regards to instances?

Jeremy Shaw wrote:

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