Make CHANGELOG.md adhere much more closely to the Keep A Changelog format

[LikeLakers2]

Resolves #253.

Some specific, noteworthy changes:

• The "Internal changes" sections under 0.7.1 and 0.9.0 have been removed - users of your library don't need (nor do they care) about internal details, so long as it works.
• The section for 0.99.4 was retitled to include [YANKED].
• Certain changes, such as the MSRV changes, or the change about all features except std being disabled by default, were reworded. This is either for clarity, or to make them fit better as changelog entries.

And some notes:

• Since all breaking changes (that I know of) were in 0.x.0 sections (and the unreleased/1.0.0 section), I did not edit them to specify "BREAKING CHANGE." Users that know about SemVer (which we can safely assume to be 99% of Rust users, due to its prevalence) will know that these versions could contain breaking changes.
• Keep A Changelog prefers that version headers link to a diff of the changes made (you can see this on Keep A Changelog's own changelog). As you haven't been using the tags functionality, I didn't bother to link those diffs.

I may perform a second pass sometime after this one is merged. I've gotten most of what I've noticed out of the way, but I still feel I could make it a little better (for example, the diff links).

Checklist

• [ ] Documentation is updated (if required)
• [ ] Tests are added/updated (if required)
• [ ] CHANGELOG entry is added (if required)

(I have not included a CHANGELOG entry as this does not apply to the library itself.)

[JelteF]

I took a quick look and most of the changes look reasonable. The main change I disagree with is the removal of the "breaking changes" section. This is the main thing people should takeaway when reading the changelog. So let's keep that section and let's keep it at the top of each version that has them.

Users that know about SemVer (which we can safely assume to be 99% of Rust users, due to its prevalence) will know that these versions could contain breaking changes.

While people indeed will know that there are breaking changes, the changelog is there to show what changes are actually breaking. It's important not to miss any, by having them "hidden" between many other less interesting changes.

There's also a pretty long ongoing discussion on the "keep a changelog" repo regarding this: olivierlacan/keep-a-changelog#480

[LikeLakers2]

I would argue against keeping it. Labeling a change specifically as "Breaking change" provides no benefit over labeling it as "Added", "Removed", or the like - especially when you consider that all versions of derive_more with breaking changes are either 0.x -> 0.y versions, or the 1.0.0 version. Anyone who understands SemVer (again, 99% of Rust users) will automatically understand that those versions could have breaking changes (documented or not), so there is no point to calling them "Breaking" when people will assume all changes within those sections will be breaking in some manner.

I can still re-add it if you still want it, but I really don't see a purpose to keeping it.

[JelteF]

so there is no point to calling them "Breaking" when people will assume all changes within those sections will be breaking in some manner.

But that's not the case. Not all of the changes in a backwards incompatible release are breaking. Many of the changes are not. So calling out the specific changes that might break something by updating is very useful to users. Which is also why this section is at the top of the changelog entry, because it's likely the most important to users. Instead of as suggested having a "Removed" section at the bottom.

So yes, please re-add. People in the discussion I linked in my previous comment use the same approach.

[LikeLakers2]

But that's not the case. Not all of the changes in a backwards incompatible release are breaking.

Man, that's not what I was saying at all. I was saying that many people assume as such, since breaking changes are only ever allowed on 0.x -> 0.y or x.0 -> y.0 releases. Whether or not it's the case that they're all breaking changes is wholly irrelevant here.

Look, just... just take my commit and edit it to your liking. I don't need credit or the like, and I don't care for the copyright of a commit like this anyways, so you can do with it as you please - including re-adding the "Breaking changes" section.

[JelteF]

I merged #256 just now, which is heavily based on this PR. Thanks for your help.