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