I've tried to refrain from endorsing tools because I feel like they risk making it easy to avoid doing what I actually encourage: curating the notable changes for a release with your mushy human brain for other mushy human brains.
I know it's hard, but perhaps it's a good constraint.
The idea that you will have the forethought of knowing when writing a commit that it'll be one of the notable entries in your future changelog seems a bit far-fetched to me. And as I tried to explain, the purpose of a commit is not the same as the purpose of a changelog entry, so there's definitely tension in the re-use of copy there.
I get the instinct to automate everything. I'm just not sure this is something that should be automated. Now, an assistive tool to help maintainers review commits for missing notable changes within a changelog, that's something I could get behind.
I think the issue with automation is it requires a cultural change for most companies / projects. People are very used to small atomic commits and so it’s hard to reduce the noise once parsed into a changelog. To make it work, you need each commit to be as meaningful as a line in the changelog.
We use Phabricator and it’s default workflow, so have a clean linear git history. Phabricator already requires strict formatting for any new diff (title, description, testing, etc). It’s built into the culture of any org using Phab to consider commits as meaningful entries in the history of the project. So it would be very straightforward (technically and culturally) to require a simple title prefix ala Changelog (ADDED, FIXED, SECURITY, etc) for each commit and have yourself a automated and meaningful log.
> you need each commit to be as meaningful as a line in the changelog.
Not really, your changelog-from-git-log generator doesn't need to incorporate every single commit. The vast majority of commits shouldn't be incorporated in a changelog anyway, since fine-grained commits serve a different purpose. It could incorporate, for example, version-change commits whose messages serve the exact same purpose as changelog entries.
git commit -m "VERSION 1.1.0 <user readable desc of changes since 1.0.0>"
I've tried to refrain from endorsing tools because I feel like they risk making it easy to avoid doing what I actually encourage: curating the notable changes for a release with your mushy human brain for other mushy human brains.
I know it's hard, but perhaps it's a good constraint.
The idea that you will have the forethought of knowing when writing a commit that it'll be one of the notable entries in your future changelog seems a bit far-fetched to me. And as I tried to explain, the purpose of a commit is not the same as the purpose of a changelog entry, so there's definitely tension in the re-use of copy there.
I get the instinct to automate everything. I'm just not sure this is something that should be automated. Now, an assistive tool to help maintainers review commits for missing notable changes within a changelog, that's something I could get behind.