Proposal: Changes to the PVP

Herbert Valerio Riedel hvr at gnu.org
Wed Apr 9 18:49:51 UTC 2014


Hello Michael,

While I can see merit in some parts[1] of this proposal, I don't agree
with this proposal as a whole.

Therefore I'm -1 on the proposal in its current form.

 [1]: E.g. having different upper-bound policies for the special class of
      the few non-upgradable packages -- however even that has
      consequences that need to be examined carefully

PS: I'd suggest breaking this proposal up into smaller incremental
    sub-proposals and discuss them one at a time.


On 2014-04-09 at 10:47:14 +0200, Michael Snoyman 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

-- 
"Elegance is not optional" -- Richard O'Keefe


More information about the Libraries mailing list