Re: Why upper bound version numbers?

Aforementioned versioning policy: https://wiki.haskell.org/Package_versioning_policy On Mon, Jun 6, 2016 at 5:58 PM, Dominick Samperi 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 wrote:

...

On Mon, Jun 6, 2016 at 8:19 PM, Dominick Samperi 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@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs