Why upper bound version numbers?
xichekolas at gmail.com
Tue Jun 7 06:14:01 UTC 2016
Aforementioned 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>
>>> 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
More information about the ghc-devs