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! :)
> 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