Why upper bound version numbers?

[Ben Lippmeier]

> On 7 Jun 2016, at 7:02 am, Dominick Samperi <djsamperi at gmail.com> wrote:
> 
> Why would a package developer want to upper bound the version number
> for packages like base? For example, the clash package requires
> 
> base >= 4.2 && base <= 4.3

I put an upper bound on all my libraries as a proxy for the GHC version. Each time a new GHC version is released sometimes my libraries work with it and sometimes not. I remember a “burning bridges” event in recent history, when the definition of the Monad class changed and broke a lot of things.

Suppose you maintain a library that is used by a lot of first year uni students (like gloss). Suppose the next GHC version comes around and your library hasn’t been updated yet because you’re waiting on some dependencies to get fixed before you can release your own. Do you want your students to get a “cannot install on this version” error, or some confusing build error which they don’t understand?

The upgrade process could be automated with a buildbot: it would try new versions and automatically bump the upper bound if the regression tests worked, but someone would need to implement it.


> Does this mean that assuming that future versions of the platform will
> remain backwards compatible with prior versions is unsafe?

My experience so far is that new GHC versions are “mostly” backwards compatible, but there are often small details that break library builds anyway. It only takes a day or so per year to fix, so I don’t mind too much.

Ben.