Proposal: Changes to the PVP

[MightyByte]

In addition to the well-state objections elsewhere in this thread, I
think this proposal is too vague and subjective.  So it gets a -1 from
me.

Point #1 needs to specify actual text.  I'm -1 on the text Michael
gives later because I disagree with that definition of reproducible
builds.

Point numbers 3 and 4 are too vague, subjective, and would cause
contention in the community.  Package authors are already free to to
associate extra meaning with A and B.  If you're willing to put in
version bounds after this PVP change, I don't see why you shouldn't be
willing to put them in before it.

On Wed, Apr 9, 2014 at 4: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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>