Proposal: Changes to the PVP

[Michael Snoyman]

On Wed, Apr 9, 2014 at 2:12 PM, Daniel Trstenjak <daniel.trstenjak at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140409/e490b65e/attachment.html>