<div dir="ltr"><div><div><div><div><div><div><div><div>My opinion is that the version number shouldn't convey the idea of stability. It should be another field :)<br></div>In fact in Cabal there is a stability field:<br><a href="https://www.haskell.org/cabal/users-guide/developing-packages.html#package-properties">https://www.haskell.org/cabal/users-guide/developing-packages.html#package-properties</a><br></div>But it's not very well specified/used.<br><br></div>Anyway the fact that we like to have "V1.0" to mean "work done" is more a question of aesthetic.<br></div>The version number carries three different informations IMO:<br></div>- tagging a specific state of the sources,<br></div><div>- give an order between the versions,<br></div>- give information about the level of changes.<br></div>The third one could be separated. It could be made into a field containing the level of changes, such as "minor changes"/"API breaking changes". Then the version tag could be made what you want, even tagging "V1.0" a minor change.<br></div>Just my 2 cent :)<br><div><div><div><div><div><div><br><div><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 16, 2014 at 12:39 PM, Vincent Hanquez <span dir="ltr"><<a href="mailto:tab@snarc.org" target="_blank">tab@snarc.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 16/12/2014 11:23, Roman Cheplyaka wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I need to wait till I have an API-breaking change in order to mark a<br>
package as stable? That's... ironic.<br>
</blockquote></span>
This is one of my issue with the PvP. with the PvP versioning you're not able to convey any other informations apart from the API "changing".<br>
<br>
Which means you can't properly convey:<br>
<br>
* major new features: by bumping the major, despite the API not changing<br>
* security (by bumping the minor or patchlevel, regardless if the API change)<br>
* the stability (bumping to 1.x).<br>
<br>
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=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, if the library is stable enough, people would constraint the A<br>
version (e.g. 'containers < 1'), asserting that their package will<br>
probably continue to build even under minor API-breaking changes which<br>
are typical for stable packages. Now, by bumping my A version for a<br>
minor breaking change, I'm acting exactly against their intention,<br>
saying "hey, this is a massive change, you'd better pay attention before<br>
using it". That's not what an actual stable package is supposed to do.<br>
<br>
</blockquote></span>
Indeed.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Vincent</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<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/<u></u>mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div></div>