<div dir="ltr"><div><div><div><div><div><div><div><div>Thanks everyone for your feedback!<br><br></div>From what I'm hearing it sounds like in the scheme "A.B.C.D" is roughly handled like this: (I know "D" isn't technically in the PVP)<br><br></div>* If the change includes a major overhaul to the design of the package, A should be bumped. Things like all modules changed, introducing a new monad that should be used instead, etc.<br></div><br>* If the change includes non-backwards compatible features that lives inside the existing design, only B should be bumped. Things like refactoring existing functions, changing the signature and/or introducing new data types for existing functions.<br><br></div>* If the change includes backwards compatible changes, only C should be bumped. Things like adding a new convenience function. Adding brand new functions/modules that didn't have any existing counterpart.<br><br></div>* (Unspoken, but many people do it) If the change includes a minor backwards compatible fix, D should be bumped. A typo in a string, a security patch that doesn't change the signature or typical behavior.<br><br></div>Changing the package's dependencies also feels like it could either end up bumping B if you're changing the minimum requirements of existing dependencies, or C if you introduce a new dependency.<br><br></div>Obviously some package maintainers will deviate from above. However, if I've summarized the typical community process, could we add these examples (or a variation of them) to <a href="https://www.haskell.org/haskellwiki/Package_versioning_policy">https://www.haskell.org/haskellwiki/Package_versioning_policy</a> ? As a newcommer, this would have helped me out to understand how people version packages and to have some idea of interpreting the version history on hackage pages. If there's not too much objection to that inclusion, is there a way I can help aid that wiki change process?<br><br><br><br><br></div>Tobias wrote:<br><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">  When you introduce a new entity in the public interface, such as a new<br>
  typeclass, a new exported type, a new exported function, etc., you<br>
  should bump the *second* number. This is because such introductions<br>
  are only breaking changes when the consumer imports your modules<br>
  unqualified and completely (i.e. `import The.Module`, not `import<br>
  qualified The.Module as TM` nor `import The.Module (foo, bar)`).<br>
  Importing your module "safely" will not break anything because the<br>
  previous entities are still there, and the new ones simply won't be<br>
  imported, so they cannot cause any clashes.</blockquote><div><div><div><div><div><div><div><br></div><div>If you ignore the case of orphan instances, from what I read of the <a href="https://www.haskell.org/haskellwiki/Package_versioning_policy">PVP</a> this is very loosely interpreting the phrase "<i>A.B</i> may remain the same...". I would honestly expect C to be bumped in this scenario instead because what you describe sounds like a backwards compatible addition. In fact it gets a little more odd since the same sentence says "...the new <i>C</i> must be greater than the old <i>C". </i>Bumping **both** B and C feels odd to me.<i><br><br><br><br><br></i></div><div>Roman wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">We saw something similar with text, people got angry. If a library becomes popular before it reaches 1.0, it probably never will.</blockquote><div> </div></div><div>Johan wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Lots of really stable Haskell libraries (e.g. containers) are still on version 0.X.</blockquote></div><div><br></div><div>Vincent wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Text is one of canonical example when it was bumped to 1.x recently and 
lots of people complained that it wasn't the right thing to do.<span class="im"><br></span></blockquote><div><br></div><div>Corentin wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Anyway the fact that we like to have "V1.0" to mean "work done" is more a question of aesthetic.</blockquote><div> </div></div><div>I know upper bound constraints is a contentious topic in the Haskell community. I was trying to avoid bringing that up altogether for these questions. Setting aside the common "at what point do the maintainer(s) commit to the existing API and mark the big 1 point 0" dilemma, very stable 0.x packages are one of the reasons why I was confused and asked the list.<br><br>It feels like the PVP encourages packages to not ever go 1.0 since bumping B (0.1, 0.2) are considered major versions, and therefore packages can continue their stable maintenance ignoring A forever (excluding major overhauls discussed above of course). In my opinion, that is confusing behavior and should not be encouraged. It's a bummer to me to hear that people got upset when Text went from 0.11 to 1.0.<br><br>Does anyone have any links to the threads where people were upset because of the Text 1.0 change? I'd like know if it was just simply because they had to change the upper bound constraint for many packages or if there was more to it than that. I found a few emails when it occurred <a href="https://www.haskell.org/pipermail/haskell-cafe/2013-December/111845.html">https://www.haskell.org/pipermail/haskell-cafe/2013-December/111845.html</a> but nothing beyond that.<br></div><div><br></div><div>-Zach<br></div><div> <br></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 16, 2014 at 11:00 AM, Felipe Lessa <span dir="ltr"><<a href="mailto:felipe.lessa@gmail.com" target="_blank">felipe.lessa@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 16-12-2014 07:18, Tobias Dammers wrote:<br>
> IIRC, the rules (for libraries at least) are (correct me if I'm wrong):<br>
<br>
</span>These are not rules encoded by the PVP.  The PVP doesn't prescribe how A<br>
or B should be changed besides stating when the major version should be<br>
bumped.  This can be accomplished by increasing either A or B, but it's<br>
entirely up to the author to decide which.  Any author is free to use<br>
whatever rule they see fit.<br>
<br>
Cheers,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Felipe.<br>
<br>
</font></span><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">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>
<br></blockquote></div><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">-Zach</div></div>
</div>