Context

I maintain a few crates that provide bitflags types in their public API, while the crates themselves don't really use these types heavily. As such I won't notice changed/missing APIs until these crates are published and used out in the wild.

Most importantly, besides listing commit/PR titles in a changelog, it should serve as a human readable "migration guide" explaining the outcome or expected action from consumer crates. Right now this appears to be lacking, forcing consumers to either blindly whack some derives on types or features on the crate dependency, or search through this repository and PRs to understand whether that's the right/intended thing to do in the first place.

Cannot derive serde on bitflags anymore

Some digging seems points to bitflags now being a newtype wrapper around an internal implementation, which requires the serde feature (disabled by default in serde: enable no-std support by @nim65s in https://github.com/bitflags/bitflags/pull/296) to be enabled to get this propagated. The entire effect of this newtype wrapper should have had a honorable mention in the changelog 🙂

EDIT: Even worse, #282 makes the following mention:

If you previously had a #[derive(Serialize)] impl, you'll need a #[serde(transparent)] attribute to ensure your format doesn't change.

Again, such kind of breakage is exactly the thing to describe in the changelog 😅

Changes to serde serialization

2.0.0-rc.2 has a big warning that the serialization format changed: https://github.com/bitflags/bitflags/blob/main/CHANGELOG.md#200-rc2, yet this warning was not propagated to the main 2.0.0 changelog: https://github.com/bitflags/bitflags/releases/tag/2.0.0

Debug, Copy, Clone, Hash, (Partial)Eq etc not automatically derived anymore

Also appears to be explicitly asked in the issues and happening as a result of the newtype wrapper, but nothing explaining this in the changelog. Would be helpful if it contains a full list of all the trait implementations that have been "removed" going from 1.3.2 to 2.0.0.

Regardless of all that, thanks for making all these changes and improvements! I'm sure they'll get appreciated, as long as such breaking effects get the attention they deserve in the changelog.