# 1.0.0 (unreleased)
-- Remove `bench` Cargo feature (by shifting benchmarks out of `src/lib.rs` into
- `benches/bench.rs`; it still won’t run on anything but nightly, but that
- don’t signify). Technically a [breaking-change], but it was something for
- development only, so I’m not in the slightest bit concerned by it.
+- Removed `anymap::any::Any` in favour of just plain `core::any::Any`, since its
+ `Send`/`Sync` story is now long stable.
-- Implement `Default` on `Map` (not just on `RawMap`)
+ - This loses `Any + Sync`. `CloneAny + Sync` is also removed for consistency.
+ (So `Any + Sync` is gone, but `Any`, `Any + Send` and `Any + Send + Sync`
+ remain, plus the same set for `CloneAny`.)
+
+- `anymap::any::CloneAny` moved to `anymap::CloneAny`.
+ With nothing public left in `anymap::any`, it is removed.
+
+- Relicensed from MIT/Apache-2.0 to BlueOak-1.0.0/MIT/Apache-2.0.
+
+- Increased the minimum supported version of Rust from 1.7.0 to 1.36.0.
+
+- no_std is now possible in the usual way (default Cargo feature 'std'),
+ depending on alloc and hashbrown.
+
+- Removed the `bench` Cargo feature which was mostly to work around historical
+ Cargo limitations, but was solved by moving benchmarks from `src/lib.rs` to
+ `benches/bench.rs` even before those limitations were lifted. The benchmarks
+ still won’t run on anything but nightly, but that don’t signify.
+
+- Implemented `Default` on `Map` (not just on `RawMap`).
+
+- Added `Entry::{or_default, and_modify}` (std::collections::hash_map parity).
+
+- Removed the `anymap::raw` wrapper layer around `std::collections::hash_map`,
+ in favour of exposing the raw `HashMap` directly. I think there was a reason
+ I did it that seven years ago, but I think that reason may have dissolved by
+ now, and I can’t think of it and I don’t like the particular safe
+ `as_mut`/unsafe insert approach that I used. Because of the hashbrown stuff,
+ I have retained `anymap::RawMap` is an alias, and `anymap::raw_hash_map` too.
+ The end result of this is that raw access can finally access things that have
+ stabilised since Rust 1.7.0, and we’ll no longer need to play catch-up.
+
+- Worked around the spurious `where_clauses_object_safety` future-compatibility lint that has been raised since mid-2018.
+ If you put `#![allow(where_clauses_object_safety)]` on your binary crates for this reason, you can remove it.
I don’t plan for there to be any real changes from 0.12.1;
it should be just a bit of housecleaning and a version bump.