On Wed, Apr 9, 2014 at 12:31 PM, Johan Tibell <johan.tibell@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@ 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