Proposal: Changes to the PVP

[Erik Hesselink]

On Wed, Apr 9, 2014 at 10: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.

I think this would be fine to add. Since part of the PVP talks about
ranges on dependency versions anyway, reproducible build are out the
window from the start. It doesn't hurt to add a sentence or two
mentioning this.

However, checking the current document, the very first paragraph says:

"The goal of a versioning system is to inform clients of a package of
changes to that package that might affect them, and to provide a way
for clients to specify a particular version or range of versions of a
dependency that they are compatible with."

It already seems pretty clear to me.

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

A lot of packages break from upgrades to base and template-haskell. I
think removing the upper bounds here will lead to a lot of confusion,
so I'm -1 on this one.

> 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.)

This sounds too vague to be an actual policy, so -1.

> 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).)

Isn't this already the case?

Erik