I very much agree with the sentiment that bounds on, say, template-haskell or ghc-prim never help build plans.

One of the most common complaints I get from users has to do with the garbage type errors they get out of the template-haskell that runs lens when some package somewhere has "upgraded" their `template-haskell` install to a non-compatible version.

By the time they discover this they are often several packages further along in the install and only have the vaguest inkling of what caused the problem in the first place.

Regarding base I still use the < 5 bound, as as Herbert pointed out if we ever needed to ship with support for two versions of base during some big cut-over, it'd be nice to have it work. That said, I'm somewhat leery of how well the community could deal with that in practice. Even the old monads-fd vs mtl split nearly rent the ecosystem asunder. ;)

-Edward

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

On Wed, Feb 26, 2014 at 2:03 PM, Johan Tibell <johan.tibell@gmail.com> wrote:

I think we should relax the PVP requirement to bump the major version number when adding an instance and instead require that the major version bump is only required when using orphan instances and otherwise only a minor version bump is required. Unless I missed some case, code that depends on a library that follows this rule should not not break.

Here's my reasoning:

If you add a non-orphan instance, it must be because

* you define the data type or the type class in your package and
* depend on a package that declares the other entity.

Therefore, no package that depend on your package can declare a non-orphan instance that could collide with the instance you declare.

+1. If we're discussing PVP changes, the other one I'd like to propose is:

Don't include upper bounds on base, template-haskell, or other libraries which cannot be upgraded, unless you know with certainty that your package will not compile with those other versions. Motivation:

* The bounds will never help cabal choose a better build plan.
* The bounds may cause valid builds to never be attempted.
* The bounds make it very difficult to check and debug new versions of GHC.

* Including the bounds if you know the build will fail makes for more user-friendly messages.
* Leaving off the bounds if you're not certain will result in users getting more verbose error messages. While uglier, these error messages will be helpful for the package maintainer to adjust the package for the new version of GHC.

I'd also want to push the bounds a little bit further a make a distinction between experimental and stable packages, but that's a bigger proposal and I'd rather start with something more modest.

Michael