Why upper bound version numbers?

[Andrew Farmer]

Aforementioned versioning policy:
https://wiki.haskell.org/Package_versioning_policy

On Mon, Jun 6, 2016 at 5:58 PM, Dominick Samperi <djsamperi at gmail.com> wrote:
> I guess what you are saying is that this policy will prevent packages
> from installing with new versions of ghc until the maintainer has had
> a chance to test the package with the new version, and has updated the
> upper version limit. Thus, inserting those upper version limits is a
> kind of flag that indicates that the package has been "certified" for
> use with versions of base less than or equal to the upper limit.
>
> On Mon, Jun 6, 2016 at 8:22 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
>> On Mon, Jun 6, 2016 at 8:19 PM, Dominick Samperi <djsamperi at gmail.com>
>> wrote:
>>>
>>> The odd thing about this is that to upper bound a package that you did
>>> not write (like base) you would have to know that incompatible changes
>>> were coming in subsequent revisions, or that features of the API that
>>> you rely on will be changed.
>>
>>
>> There is a versioning policy covering this. It has been found to be
>> necessary because otherwise people who try to build packages find themselves
>> with broken messes because of the assumption that any future version of a
>> package is guaranteed to be compatible.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine associates
>> allbery.b at gmail.com                                  ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs