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@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@snoyman.com
> <mailto:michael@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