Why upper bound version numbers?

[Reid Barton]

On Tue, Jun 7, 2016 at 9:31 AM, Ben Lippmeier <benl at ouroborus.net> wrote:

>
> > 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?
>

This is a popular but ultimately silly argument. First, cabal dependency
solver error messages are terrible; there's no way a new user would figure
out from a bunch of solver output about things like "base-4.7.0.2" and
"Dependency tree exhaustively searched" that the solution is to build with
an older version of GHC. A configuration error and a build error will both
send the same message: "something is broken". Second, this argument ignores
the much more likely case that the package would have just worked with the
new GHC, but the upper bound results in an unnecessary (and again,
terrible) error message and a bad user experience. The best case is that
the user somehow learns about --allow-newer=base, but cabal's error message
doesn't even suggest trying this and it's still an unnecessary hoop to jump
through.

Experienced users are also only harmed by these upper bounds, since it's
generally obvious when a program fails to build due to a change in base and
the normal reaction to a version error with base is just to retry with
--allow-newer=base anyways.

Of course the best thing is to stick to the part of the language that is
unlikely to be broken by future versions of base; sadly this seems to be
impossible in the current climate...

Regards,
Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160608/89ff16bb/attachment.html>