> I don't expect end-users of most open source software to be satisfied with either the high-level nature of commit titles, or their minutia.
In my experience, they aren't. They want a top-level view of why/if they should upgrade.
In my dayjob, when preparing a release, we use tools to dump the git commit messages into the head of the CHANGELOG, then edit it back into user-facing text. We omit changes that are not user-facing (eg. 'gem you've never heard of upgraded to 0.4.4') and focus on changes they care about (eg. 'Redact credentials from URLs in a cached buildpack's output'). See for example our Ruby buildpack CHANGELOG[0].
We build our own binaries for buildpacks. So in addition, for our Github releases, we take the CHANGELOG entry and append a table of supported binaries and default versions[1]. These show up in the CHANGELOG only if we add or drop a core binary.
We work out of Tracker, so we link to Tracker stories, bugs and chores for every mentioned in the CHANGELOG or release notes.
In my experience, they aren't. They want a top-level view of why/if they should upgrade.
In my dayjob, when preparing a release, we use tools to dump the git commit messages into the head of the CHANGELOG, then edit it back into user-facing text. We omit changes that are not user-facing (eg. 'gem you've never heard of upgraded to 0.4.4') and focus on changes they care about (eg. 'Redact credentials from URLs in a cached buildpack's output'). See for example our Ruby buildpack CHANGELOG[0].
We build our own binaries for buildpacks. So in addition, for our Github releases, we take the CHANGELOG entry and append a table of supported binaries and default versions[1]. These show up in the CHANGELOG only if we add or drop a core binary.
We work out of Tracker, so we link to Tracker stories, bugs and chores for every mentioned in the CHANGELOG or release notes.
[0] https://github.com/cloudfoundry/ruby-buildpack/blob/master/C...
[1] https://github.com/cloudfoundry/ruby-buildpack/releases/tag/...