Thing is, that if this is the design goal of the PVP, then _any_ addition to the exports of a module should necessitate a major version bump, because of the potential for clashing unqualified, non-explicit imports. The reasoning for this seems to be that the chances are low (very context dependent) and unqualified, non-explicit imports are discouraged and bad style. Orphan instances are also discouraged, so for consistency with the policy for regular additions, it would make sense for libraries adding instances to only necessitate a minor version bump. I don't think that commenting out an instance in bar should really be considered "developing" bar. Certainly anyone that wants to stay on the bleeding edge of ghc or cabal is going to need to get their hands dirty now and then. I'd prefer this relatively rare circumstance to the frequent, painful circumstance where upper bounds are too restrictive. Editing version bounds is certainly as invasive as commenting out an instance, and more opaque to those not well versed in cabal-foo. As I've expressed elsewhere, I think there are a bunch of things that could alleviate dependency hell to varying degrees. These are just stop-gaps / changes to conventions in the meantime. Right now it's pretty bearable - hackage is bigger - but not giant. People are doing stuff - but packages aren't being updated every minute. I'd like to see a solution that works well, giving client assurance of compatibility, while giving library designers freedom to change. If this isn't figured out well, things're going to get a lot uglier during the exponential part of Haskell's (optimistically) anticipated "hockey-stick" growth. Thanks! -mgsloan On Wed, Sep 5, 2012 at 6:07 PM, Ian Lynagh <igloo@earth.li> wrote:
On Wed, Sep 05, 2012 at 05:43:04PM -0700, Michael Sloan wrote:
While I suppose it could break proper dependency resolution, a big reason for upper bounds is preventing a cascade of confusing errors. With orphan instances the errors are very finite.
I don't think the type of errors was a factor in designing the PvP. The primary (perhaps even only) goal was to design packages in such a way that if "cabal install foo" would have worked yesterday, then it will also work today.
That means that if foo depends on bar, and there is a suitable newer version of bar available today, then foo had better work with that version too.
The person installing foo isn't interested in developing foo or bar, so doesn't want any error at all!
Thanks Ian
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries