On Wed, Apr 9, 2014 at 2:12 PM, Daniel Trstenjak 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/...