<div dir="ltr">+1 I would appreciate this.<input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"expires":false,"isManaged":false},"attachments":{},"compose-window":{"secure":false}}"><div class="gmail_extra" style="display:block"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">-- Dan Burton</div></div>
<br><div class="gmail_quote">On Tue, Jan 16, 2018 at 10:35 AM, Ben Gamari <span dir="ltr"><<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
TL;DR. We propose to start following the PVP for core libraries shipped<br>
       with GHC alpha release. Let us know what you think.<br>
<br>
<br>
Hello everyone,<br>
<br>
GHC has recently been reworking its release policy, increasing the<br>
release cadence to two releases per year. We hope that this change<br>
facilitates earlier and more thorough testing of GHC. Of course,<br>
a compiler is worth little if no real-world packages can be built with<br>
it.<br>
<br>
Historically library maintainers have been reluctant to offer releases<br>
claiming compatibility with pre-release GHCs due to the lax versioning<br>
guarantees offered by such pre-releases. Specifically, changes to<br>
libraries shipped with GHC pre-releases have historically not had<br>
proper distinct version numbers, causing unnecessary breakage for<br>
released code (e.g. [1]).<br>
<br>
To make maintainers feel more at ease with releasing libraries<br>
compatible with GHC alpha releases, we propose to start using the<br>
Package Versioning Policy (PVP) [2] to version GHC's core libraries with<br>
each alpha release. That is, libraries which are not source-identical<br>
will get at very least a minor bump with each alpha release.<br>
<br>
By "core libraries" we mean the set of:<br>
<br>
 * base<br>
 * template-haskell<br>
 * integer-gmp<br>
 * integer-simple<br>
 * hpc<br>
 * ghci<br>
 * ghc-compact<br>
 * all GHC dependencies not maintained by GHC HQ<br>
 * ghc-prim<br>
 * ghc-boot<br>
 * ghc-boot-th<br>
<br>
Following the PVP will allow maintainers to safely release libraries to<br>
Hackage without fear that they will break when the final GHC 8.4.1<br>
release is made, easing the testing process for everyone.<br>
<br>
If you have an opinion one way or another on this matter please do share<br>
it on this list.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
<br>
[1] <a href="https://github.com/tibbe/hashable/issues/143" rel="noreferrer" target="_blank">https://github.com/tibbe/<wbr>hashable/issues/143</a><br>
[2] <a href="https://pvp.haskell.org/" rel="noreferrer" target="_blank">https://pvp.haskell.org/</a><br>
<br>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div><br></div></div>