As someone who recurrently is nudging a large number of maintainers every major ghc release to bump their bounds, I favor the no upper bounds approach! :)

plus the whole improving ecosystem of build bot tools which play nice with cabal et al that are cropping up mean that "in principal" we could debug missing upper bounds via sort of temporal bisecting over the "event stream" of maximum available versions at a given time to sort that. (but that piece isn't that important)

more pragmatically, cabal when used with hackage doesn't let you override version constraints, it just lets you add additional constraints. This makes sense if we assume that the library author is saying "things will definitely break if you violate them", but in practice upper bounds are made up guesstimation. 

YES, its presumably semantic versioning doesn't create a problem, but with the hackage eco system, when dealing with intelligently engineering libs that are regularly maintained, version upper bounds create more problems than than solve.

just my two cents. (yes yes yes, please drop upper bounds!)

cheers
-Carter

On Wed, Aug 15, 2012 at 5:04 PM, Michael Blume <blume.mike@gmail.com> wrote:
> it's usual for the existing upper bounds to refer to versions that don't exist at the time of writing (and hence can't be known to be stable).

Well, known to be stable given semantic versioning, then.

http://semver.org/

On Wed, Aug 15, 2012 at 1:55 PM, Bryan O'Sullivan <bos@serpentine.com> wrote:
> On Wed, Aug 15, 2012 at 1:50 PM, David Thomas <davidleothomas@gmail.com>
> wrote:
>>
>> Would it make sense to have a known-to-be-stable-though soft upper bound
>> added proactively, and a known-to-break-above hard bound added reactively,
>> so people can loosen gracefully as appropriate?
>
> I don't think so. It adds complexity, but more importantly it's usual for
> the existing upper bounds to refer to versions that don't exist at the time
> of writing (and hence can't be known to be stable).
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe