For those saying “just use commit history”, I once had to sift through 200 commits because the library author was too lazy to separate the breaking changes from the patches. It’s horrible for users of your library, a changelog doesn’t have to replicate your commit log but it should at the least be the “highlights” or need-to-know version of it.
> For those saying “just use commit history”, I once had to sift through 200 commits
Exactly... I think it's a good idea to "roll up" the impact of the changes so that users and external developers can easily understand what was changed without getting too "in the weeds"- raw commit messages are generally the opposite of that.
> GitHub have developed a feature to generate release notes
The annoying part here is that if you are using a branch-based CI auto-deployment (without an "Approve" step) then you have to push the branch before writing the release notes. Anyway I just do `git cherry -v release` or so from `main` (for instance) and paste the results into the Release Notes at the bottom and put my summaries at the top. The benefit of just pasting the results is that Github will detect the commit IDs and link to them automatically. It makes for a pretty good experience where you can sum it up and have the full commit messages for those interested.
For those saying “just use commit history”, I once had to sift through 200 commits because the library author was too lazy to separate the breaking changes from the patches. It’s horrible for users of your library, a changelog doesn’t have to replicate your commit log but it should at the least be the “highlights” or need-to-know version of it.