Proposal: Changes to the PVP

[Johan Tibell]

On Wed, Apr 9, 2014 at 9:22 PM, Michael Snoyman <michael at snoyman.com> wrote:
>
> So forget my proposal for the moment, I want to engage in a thought
> experiment. What does the current PVP say about the following scenarios:
>
> 1. A user is writing an application based on a number of Hackage
> libraries. He places version bounds following the PVP, e.g. `text >= 1.0 &&
> < 1.1, aeson >= 0.7 && < 0.8`.
>     a. Has he done a good enough job of writing his application?
>

That's a kinda vague question. :) Has he made sure that his package will
continue to build if there are backwards incompatible changes in text or
aeson? Yes.


>     b. Should he have an expectation that, no matter what happens, his
> software will always build when running `cabal clean && cabal install`
> (assuming same GHC version and OS)?
>

"No matter what happens" is also kinda vague. Assuming no bugs in GHC,
Cabal, etc and assuming he's using a hermetic build environment (such as
sandboxes), yes. The reason a hermetic build environment is needed is that
otherwise unrelated packages might constrain the build environment (i.e.
the infamous "building X will break Y" problems of the past.)


>     c. Should he have an expectation that the code will always run in the
> same way it did when first built?
>

No. text or aeson might introduce bugs in minor/patch releases. The code
might run differently on different platforms (e.g. due to different word
sizes).


> 2. I author a package called foo and release version 1.2 with the
> statement: "I guarantee that the Foo module will exist and continue to
> export the foo1 and foo2 functions, with the same type signature, until
> version 2.0."
>     a. If a user of the foo package only uses the foo1 and foo2 functions,
> is he "in violation" of the PVP by using a bound on the foo package of `foo
> >= 1.2 && < 2`?
>

No.

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