+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.

On Tue, Feb 13, 2018 at 2:28 PM, Herbert Valerio Riedel <hvriedel@gmail.com> wrote:

David,

On 2018-02-13 at 14:33:45 -0500, David Feuer wrote:

[...]

> 1. Deprecate the Semigroup and Monoid instances for Data.Map.Map,
> Data.IntMap.IntMap, and Data.HashMap.HashMap in the next releases of
> containers and unordered-containers.
>
> 2. Remove the deprecated instances.
>
> 3. After another several years (four or five, perhaps?), make a major
> release of each package in which the instances are replaced with the
> following:

Why does this need to be a such a dreadfully long-winded process? All we
need is a way to somehow signal a semantic change in the exposed API --
and it turns out that we actually already have the technology for this!

This is exactly one of the core ideas of "semantic versioning" (as a
dep-solver-computation-friendly proxy for machine-checkable formal API
contracts...) and it's got even "semantic" in its name!

In other words, the proposal can be greatly simplified to

1. Make a new major release (or maybe even make it a super-major
release, i.e. to `containers-1.0.0.0` for extra saliency) replacing
the instances with the more desirable ones; describe the change
prominently in the changelog.

Profit!

Life's short; do we really need a multi-generational journey where the
original supporters may not even be around anymore to see the proposal
reach its final destination... ;-)

Cheers,
HVR

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries