On Wed, Apr 9, 2014 at 2:12 PM, Daniel Trstenjak <daniel.trstenjak@gmail.com> wrote:

Hi Michael,

On Wed, Apr 09, 2014 at 01:29:18PM +0300, Michael Snoyman wrote:
> * From a library maintainer standpoint: decreased maintenance overhead. Being
> able to say `text < 2` or `case-insensitive < 2` means less time spent fiddling
> with cabal files.

I think that's mostly a tooling issue. It was my main motivation for
writing 'cabal-bounds' (https://github.com/dan-t/cabal-bounds).

While that can certainly *help*, the burden is still there. Even something as trivial as "go to dev machine, edit cabal file to say 1.2 instead of 1.1, cabal sdist, cabal update" takes time. If you want to do it properly (push to Github, wait for Travis to run test suites) it takes even more time.

> * From a library user standpoint: it makes it less likely that you'll run into
> a case where cabal cannot create a build plan. If package foo places a
> restrictive upper bound on text of `text < 1.1`, and package bar starts using a
> new feature in text 1.1 and therefore has a bound `text >= 1.1`, the user won't
> be able to use foo and bar together until the author of foo bumps the version
> number.

Yes, that's certainly a problem, but otherwise you also can't be sure
that 'text 1.1' didn't introduce a breaking change.

With this proposal, you can: we'd establish rules that you *can* depend on certain API subsets for a longer version range. So if I use that subset, I can be certain that 1.1 doesn't introduce a breaking change*.

* Unless of course the maintainer violates the agreement he's made with the users, but that's the same situation we're in right now with PVP upper bounds in general.

So with the new cabal flag '--allow-newer' the user could still try to build
with 'text 1.1' and the package could still indicate that it wasn't tried
with 'text 1.1', which at the end seems to be the best of both worlds.

There are two downsides to this:

* The goal is to simplify this process for end users. If the answer is "use --allow-newer," we're then (1) expecting end users to know this advice, and (2) we're removing most of the benefits of upper bounds. Like most things, either too much or too little is a bad thing. We need meaningful upper bounds to be enforced.

* --allow-newer conflates two concepts: upper bounds put in place due to a known breakage, and upper bounds put in place due to unknown changes. This isn't news: the fact that there's no such distinction in cabal for this has been brought up in the past. I gave an example of this problem on Reddit[1].

Michael

[1] http://www.reddit.com/r/haskell/comments/22jlis/proposal_changes_to_the_pvp/cgny3f3