[Haskell-cafe] PVP question

[Johan Tibell]

The PVP is more specific than this and allows you to communicate how the
API changes and what downstream packages can depend on. From the PVP:

> 2. Otherwise, if only new bindings, types, classes, non-orphan instances
or modules (but see below) were added to the interface, then A.B may remain
the same but the new C must be greater than the old C. Note that modifying
imports or depending on a newer version of another package may cause extra
non-orphan instances to be exported and thus force a minor version change.

So it's clear that adding a function requires a minor version bumps and
it's also what that means for downstream packages:

> Often a package maintainer wants to add to an API without breaking
backwards compatibility, and in that case they can follow the rules of
point 2, and increase only C. A client can specify that they are
insensitive to additions to the API by allowing a range of C values, e.g.
build-depends: base >= 2.1.1 && < 2.2.

("insensitive to additions to the API" links to
https://www.haskell.org/haskellwiki/Import_modules_properly.)

So yes, if you use open imports and allow new minor versions, your code
might break. This is expected.

What's not clear here is that this rule might a bit stricter than necessary:

> 1. If any entity was removed, or the types of any entities or the
definitions of datatypes or classes were changed, or orphan instances were
added or any instances were removed, then the new A.B must be greater than
the previous A.B. Note that modifying imports or depending on a newer
version of another package may cause extra orphan instances to be exported
and thus force a major version change.

According to this rule Michael's change requires a major version bump.
However, there might be backwards compatible type changes that could be
covered under rule 2 which are not. Whether Michael's change is such a type
change is what we're trying to figure out in this thread.

-- Johan

On Mon, Dec 15, 2014 at 6:10 PM, Roman Cheplyaka <roma at ro-che.info> wrote:
>
> Almost any API change can break existing code.
>
> For example, adding a new function can break code.
>
> I thought the guiding principle for PVP was how likely it is that a
> piece of client code will break, not if that's theoretically possible.
>
> On 15/12/14 11:44, Johan Tibell wrote:
> > I think the question is: can this change cause existing code to stop
> > compiling (perhaps assuming people aren't using -Werror)? I don't think
> > it can but perhaps generalizing the type could make type inference fail
> > somewhere due to an ambiguous type.
> >
> > We really need a PVP guide that just lists lots of examples, each with a
> > note of what kind of change it is (i.e. major, minor, or patch).
> >
> > On Mon, Dec 15, 2014 at 10:00 AM, Michael Snoyman <michael at snoyman.com
> > <mailto:michael at snoyman.com>> wrote:
> >
> >     I'm a little bit uncertain of the PVP guidelines in a certain
> >     case[1], so I'd like to get some guidance/clarity. Suppose I have a
> >     library which provides the function:
> >
> >     myFunction :: IO ()
> >     myFunction = forever $ putStrLn "Still here" >> threadDelay 10^6
> >
> >     Later, I realize (or someone points out to me) that I've
> >     over-specified the type signature, and really myFunction should be:
> >
> >         myFunction :: IO a
> >
> >     In this case, does the PVP specify that we should have a minor or a
> >     major version bump? I'm not certain if this counts as a breaking
> >     change or not.
> >
> >     [1] https://github.com/fpco/streaming-commons/pull/13
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141215/dd9db3e7/attachment-0001.html>