Consider adding a default entry for empty changelog release entries in monorepos

[rekmarks]

Currently, if a monorepo package is released during a major version bump but hasn't changed, the changelog is by default empty. We should consider adding some kind of default so as to not confuse readers.

[Gudahtt]

It would be somewhat complicated to determine whether there was a real breaking change or not, since peer dependency changes might sometimes be breaking and other times not. I'm not sure we should attempt automating this - we might be better off just manually writing a note explaining whether it's breaking or not, and why.

[rekmarks]

I think we're talking past each other. I'm not trying to automate anything that isn't already automated, I'm suggesting that we add a default change entry in cases where there were no changes whatsoever. Currently, the entire release entry is empty when that happens. Motivated by your comment here: MetaMask/eslint-config#198 (comment)

[Gudahtt]

Yes, I realize that. What I mean is that there is no one default entry that would be appropriate for all situations. Minimally a changelog entry for a major release should explain why it was breaking (if it was), and I'm not sure we can determine that automatically. So any default message would be insufficient.

[rekmarks]

Hm, well for major version bumps, we could certainly do what you've done here: https://github.com/MetaMask/eslint-config/pull/212/files

[Gudahtt]

Not necessarily. There might have been other breaking changes aside from the peer dependency change. Also there might not be a peer dependency change (e.g. what if one of the "leaf" packages was the one that had the breaking change).