<br><br><div class="gmail_quote">On Sat, May 9, 2009 at 10:32 PM, Don Stewart <span dir="ltr"><<a href="mailto:dons@galois.com">dons@galois.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
duncan.coutts:<br>
<div class="im">> The question is this:<br>
><br>
> Should we allow compatible API additions to a library in a minor<br>
> release of the platform?<br>
><br>
> The choice is between allowing only bug fixes in minor releases,<br>
> or also allowing new features that add APIs but do not change<br>
> any existing APIs.<br>
<br>
<br>
</div>I'd like to ensure that the Haskell Platform respects the minor<br>
versioning policy for its constituent parts, specified,<br>
<br>
<a href="http://haskell.org/haskellwiki/Package_versioning_policy#Version_numbers" target="_blank">http://haskell.org/haskellwiki/Package_versioning_policy#Version_numbers</a><br>
<br>
That is, if a library author follows the minor version number bump<br>
policy, then they can reasonably expect to have that library bump<br>
included in the next minor bump of the platform.<br>
<br>
If we agree on this, a lot of the decision making for library bumps<br>
becomes automated. If we don't, we have to distinguish case-by-case<br>
whether a library bump added to the API.<br>
<br>
Summary: the Platform policy should follow the policy of its consituent parts.</blockquote><div><br>I agree with this.<br><br>If the platform will eventually becomes available as a cabal-installable package I expect it to follow the PVP. That means that bumping the third version component implies (possible) API additions. Any library that wants to depend on the HP and only get bug-fix updates should specify a x.y.z.* dependency on HP. If we decide that a minor version increase in the HP package's version means bug-fix release these libraries won't benefit from that bug-fix release.<br>
<br>Cheers,<br><br>Johan<br><br></div></div><br>