Proposal: Changes to the PVP

Michael Snoyman michael at snoyman.com
Wed Apr 9 10:23:29 UTC 2014


On Wed, Apr 9, 2014 at 12:31 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> (1) I would never say no to making something more clear. The goal is
> currently given in the first few paragraphs of the PVP. Please give the
> actual text you'd like to see.
>
> The current goal can be summarized as: give a meaning to version numbers.
> The reason for that goal was problems with unbuildable packages that we
> experienced prior to the PVP.
>
> I don't see how the PVP as written anywhere suggests that the PVP aspires
> to provide reproducible builds. It only talks about compatible APIs.
>
>
Nonetheless, there is definitely confusion. The easiest way to see that is
to look at the Reddit discussion of the blog post[1]. For example:

> Which implicitly includes supporting reproducible builds for
"non-published software"

There are other examples in that discussion, as well as in the
libraries at discussion. My proposed addition to the PVP itself would be
the text:

While PVP compliance makes getting a successful build more likely, it does
not try to encourage reproducible builds: builds which use exactly the same
dependencies as previous builds. In particular: minor version bumps and
changes in transitive dependencies can easily slip in. Reproducible builds
are highly recommended for building production executables, and for that,
dependency freezing is the only known solution (to be included in
cabal-install after version X).

[1]
http://www.reddit.com/r/haskell/comments/22jlis/proposal_changes_to_the_pvp/


> (2) I'm somewhat ambivalent about removing the upper bounds for the 3
> packages that are not upgradable (base, template-haskell, and ghc-prim). On
> one hand removing upper bounds doesn't introduce additional breakages and
> avoids having maintainers bump bounds on each GHC release* (~yearly), but
> on the other hand it creates worse error messages**. The solver could tell
> the user "Your package doesn't work with the version of base you have
> installed." instead of giving them a potentially confusing compilation
> error.
>
> * I find it quite disconcerting that we bump the major version of base on
> every release. We shouldn't make breaking changes to the most core of core
> libraries on every release! I also note that GHC 7.4.1 seems to have bumped
> the major version on base even though no breaking change was made:
> https://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html
>
>
Though it's really a separate discussion, +1 on the idea of decreasing
frequency of major version bumps in base and template-haskell.


> ** Although Cabal's dependency solver doesn't give the best messages today
> either. But at least it could be improved.
>
>  (3) This is already the case. We just don't encourage authors to do it
> (as maintaining version information in documentation rather than
> machine-checkable contracts tends to be hard to maintain.)
>
>
>
Yet in this same thread Erik said:

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

So it seems like the intention of the PVP itself is unclear at this point.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140409/e9394322/attachment-0001.html>


More information about the Libraries mailing list