Proposal: Changes to the PVP

Michael Snoyman michael at snoyman.com
Wed Apr 9 19:22:16 UTC 2014


I have to say, the responses on this thread are truly confusing. Let's
ignore point (3) of my proposal (since it can essentially be subsumed under
(4)). Point (2) is clearly a change in the PVP, and boils down to "users
get cabal error messages" or "users get GHC error messages." I understand
(though strongly disagree with) those opposed to the change I'm proposing
there. So let's ignore it.

For (1) and (4), the responses vary from support, to opposition, to "that's
what the PVP already says." So there's clearly a problem here, and I don't
think the problem is in my proposal: people have very different ideas of
what the PVP actually expects of us.

So forget my proposal for the moment, I want to engage in a thought
experiment. What does the current PVP say about the following scenarios:

1. A user is writing an application based on a number of Hackage libraries.
He places version bounds following the PVP, e.g. `text >= 1.0 && < 1.1,
aeson >= 0.7 && < 0.8`.
    a. Has he done a good enough job of writing his application?
    b. Should he have an expectation that, no matter what happens, his
software will always build when running `cabal clean && cabal install`
(assuming same GHC version and OS)?
    c. Should he have an expectation that the code will always run in the
same way it did when first built?
2. I author a package called foo and release version 1.2 with the
statement: "I guarantee that the Foo module will exist and continue to
export the foo1 and foo2 functions, with the same type signature, until
version 2.0."
    a. If a user of the foo package only uses the foo1 and foo2 functions,
is he "in violation" of the PVP by using a bound on the foo package of `foo
>= 1.2 && < 2`?



On Wed, Apr 9, 2014 at 11:47 AM, Michael Snoyman <michael at snoyman.com>wrote:

> I would like to propose the following changes to the PVP. These are the
> same changes that I recently published on the Yesod blog[1]. For more
> information on the motivations behind these changes, please see that blog
> post.
>
> 1. The goal of the PVP needs to be clarified. Its purpose is not to ensure
> reproducible builds of non-published software, but rather to provide for
> more reliable builds of libraries on Hackage. Reproducible builds should be
> handled exclusively through version freezing, the only known technique to
> actually give the necessary guarantees.
>
> 2. Upper bounds should not be included on non-upgradeable packages, such
> as base and template-haskell (are there others?). Alternatively, we should
> establish some accepted upper bound on these packages, e.g. many people
> place base < 5 on their code.
>
> 3. We should be distinguishing between mostly-stable packages and unstable
> packages. For a package like text, if you simply import Data.Text (Text,
> pack, reverse), or some other sane subset, there's no need for upper
> bounds. (Note that this doesn't provide a hard-and-fast rule like the
> current PVP, but is rather a matter of discretion. Communication between
> library authors and users (via documentation or other means) would be vital
> to making this work well.)
>
> 4. For a package version A.B.C, a bump in A or B indicates some level of
> breaking change. As an opt-in approach, package authors are free to
> associated meaning to A and B beyond what the PVP requires. Libraries which
> use these packages are free to rely on the guarantees provided by package
> authors when placing upper bounds. (Note that this is very related to point
> (3).)
>
> Discussion period: 3 weeks.
>
> [1] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140409/a9c03a98/attachment-0001.html>


More information about the Libraries mailing list