Why upper bound version numbers?
djsamperi at gmail.com
Tue Jun 7 00:58:34 UTC 2016
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>
>> 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
More information about the ghc-devs