<div dir="ltr">+1 to HVR's suggestion, this could be a great opportunity to clean out all the old cruft from the containers and unordered-containers APIs in one go. That combined with all the documentation improvements would warrant a 1.0.0.0 for both packages IMHO :) I'd be happy to help with figuring out what that 1.0.0.0 API could/should look like, since it should almost certainly include a lot of community input/feedback.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 13, 2018 at 2:28 PM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">David,<br>
<br>
<br>
On 2018-02-13 at 14:33:45 -0500, David Feuer wrote:<br>
<br>
[...]<br>
<span class=""><br>
> 1. Deprecate the Semigroup and Monoid instances for Data.Map.Map,<br>
> Data.IntMap.IntMap, and Data.HashMap.HashMap in the next releases of<br>
> containers and unordered-containers.<br>
><br>
> 2. Remove the deprecated instances.<br>
><br>
> 3. After another several years (four or five, perhaps?), make a major<br>
> release of each package in which the instances are replaced with the<br>
> following:<br>
<br>
</span>Why does this need to be a such a dreadfully long-winded process? All we<br>
need is a way to somehow signal a semantic change in the exposed API --<br>
and it turns out that we actually already have the technology for this!<br>
<br>
This is exactly one of the core ideas of "semantic versioning" (as a<br>
dep-solver-computation-<wbr>friendly proxy for machine-checkable formal API<br>
contracts...) and it's got even "semantic" in its name!<br>
<br>
<br>
In other words, the proposal can be greatly simplified to<br>
<br>
<br>
1. Make a new major release (or maybe even make it a super-major<br>
   release, i.e. to `containers-1.0.0.0` for extra saliency) replacing<br>
   the instances with the more desirable ones; describe the change<br>
   prominently in the changelog.<br>
<br>
<br>
Profit!<br>
<br>
<br>
Life's short; do we really need a multi-generational journey where the<br>
original supporters may not even be around anymore to see the proposal<br>
reach its final destination... ;-)<br>
<br>
<br>
Cheers,<br>
  HVR<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>