<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 15, 2014 at 8:24 PM, Dan Burton <span dir="ltr"><<a href="mailto:danburton.email@gmail.com" target="_blank">danburton.email@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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."</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div>-- Dan Burton</div></div>
<br></font></span><div class="gmail_quote"><div><div class="h5">On Mon, Dec 15, 2014 at 9:10 AM, Roman Cheplyaka <span dir="ltr"><<a href="mailto:roma@ro-che.info" target="_blank">roma@ro-che.info</a>></span> wrote:</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Almost any API change can break existing code.<br>
<br>
For example, adding a new function can break code.<br>
<br>
I thought the guiding principle for PVP was how likely it is that a<br>
piece of client code will break, not if that's theoretically possible.<br>
<span><br>
On 15/12/14 11:44, Johan Tibell wrote:<br>
> I think the question is: can this change cause existing code to stop<br>
> compiling (perhaps assuming people aren't using -Werror)? I don't think<br>
> it can but perhaps generalizing the type could make type inference fail<br>
> somewhere due to an ambiguous type.<br>
><br>
> We really need a PVP guide that just lists lots of examples, each with a<br>
> note of what kind of change it is (i.e. major, minor, or patch).<br>
><br>
> On Mon, Dec 15, 2014 at 10:00 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a><br>
</span></div></div><div><div><div><div class="h5">> <mailto:<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>>> wrote:<br>
><br>
>     I'm a little bit uncertain of the PVP guidelines in a certain<br>
>     case[1], so I'd like to get some guidance/clarity. Suppose I have a<br>
>     library which provides the function:<br>
><br>
>     myFunction :: IO ()<br>
>     myFunction = forever $ putStrLn "Still here" >> threadDelay 10^6<br>
><br>
>     Later, I realize (or someone points out to me) that I've<br>
>     over-specified the type signature, and really myFunction should be:<br>
><br>
>         myFunction :: IO a<br>
><br>
>     In this case, does the PVP specify that we should have a minor or a<br>
>     major version bump? I'm not certain if this counts as a breaking<br>
>     change or not.<br>
><br>
>     [1] <a href="https://github.com/fpco/streaming-commons/pull/13" target="_blank">https://github.com/fpco/streaming-commons/pull/13</a><br>
<br></div></div><span class="">
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</span></div></div></blockquote></div></div>
</blockquote></div></div></div>