<meta http-equiv="content-type" content="text/html; charset=utf-8">On 7 June 2011 15:05, James Cook <span dir="ltr">&lt;<a href="mailto:mokus@deepbondi.net">mokus@deepbondi.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div class="im">It&#39;s good, in my opinion, to be able to state succinctly in a standardized way that, although it does something now, what the code does and how it does it are probably going to change in the future.</div>

</blockquote><div><br></div><div>I think no one really updates this field and it&#39;s a human factor that could otherwise be generated by Hackage reliably. I&#39;m using many packages that are &quot;experimental&quot; or &quot;unstable&quot; that&#39;ve been stable for a year or more. The field is mostly useless to me. The stability of a package can be judged based on how often the versions bump up based on the PVP and/or the exports of the package change, that is something Hackage could trivially do. Agreed, the naming is also ambiguous, “API stability” seems more straight-forward.</div>