
On Mon, Dec 15, 2014 at 8:24 PM, Dan Burton
Or, since the PVP already encourages a cautious over-estimate of what constitutes a breaking change, perhaps we should go with this fallback: "when in doubt, call it a major change."
I think this makes sense. Unless you can convince yourself that the change doesn't break backwards compatibility (i.e. doesn't break code that uses only qualified imports and/or explicit import lists) bump the major version number. We should take the guesswork out of this. We should enumerate all possible API change variations and the corresponding version number bump. Even better, we should have a tool (like Elm has) that does so for you.
-- Dan Burton
On Mon, Dec 15, 2014 at 9:10 AM, Roman Cheplyaka
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
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.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe