Why upper bound version numbers?

[Dominick Samperi]

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