I don't disagree in general, but I think "because it's frequently full of things that are inconsequential for users" should not be a good reason.
The idea behind auto-generating the changelog with a tool like git-cliff is to use it in conjunction with conventions on your commit messages like Conventional Commits [1]. This gives you fine grained control about what will appear in the changelog.
What you do, is to move the decision whether some information ought to appear in the changelog from the time of release to the time of the commit. You also shift the responsibility from the release manager to the individual developers. The big advantage of this process is that it is much harder to forget to include things.
If that is a good idea depends on your project and team. For open source projects, where everything is public anyways, the generated changelog could act as a pretty-printed, filtered and limited view of the git history.
For proprietary software I believe the commit messages should be a space where the developers can express themselves without having to worry about that anything they write could end up at the customer (which I presume is the ultimate consumer of the changelog).
I also think there is a difference between a changelog and release notes with the former not being a replacement for the latter. For a good example how in my opinion useful release notes could look like see [2].
Apart from all of that git-cliff is an excellent implementation.
> I also think there is a difference between a changelog and release notes with the former not being a replacement for the latter. For a good example how in my opinion useful release notes could look like see [2].
My knee-jerk reaction is that now we’re just inventing something to sandwich in-between two already existing and useful things: the git log and the curated end-user change documentation.
>What you do, is to move the decision whether some information ought to appear in the changelog from the time of release to the time of the commit.
Which doesn't make any sense.
20 commits/PRs might fit together in as one line in the changelog. There is nothing that one can write in any one of those commits that make any sense at the time of commiting.
ratatui.rs is a library, whoever reads that changelog are potentially interested in the nitty gritty details. But I'd say it is the exception rather than rule, and even in that case it is only sensible for projects of a certain size with a certain release cadence.
Still, stuff like:
7a48c5b (cell) Add EMPTY and
(const) new method by @EdJoPaTo in #1143
This simplifies calls to
`Buffer::filled` in tests.
feels questionable to have in the changelog either way. Unless that for some reason has a great impact for users (could be, didn't read into it).
Doing what teamcity does takes some effort. And I guess my gripe is the belief that these conventional commits will save the majority of work of the release notes. It can be a convenience but it needs curation and work to be presentable. And most projects seem to pick them to avoid that work.
The idea behind auto-generating the changelog with a tool like git-cliff is to use it in conjunction with conventions on your commit messages like Conventional Commits [1]. This gives you fine grained control about what will appear in the changelog.
What you do, is to move the decision whether some information ought to appear in the changelog from the time of release to the time of the commit. You also shift the responsibility from the release manager to the individual developers. The big advantage of this process is that it is much harder to forget to include things.
If that is a good idea depends on your project and team. For open source projects, where everything is public anyways, the generated changelog could act as a pretty-printed, filtered and limited view of the git history.
For proprietary software I believe the commit messages should be a space where the developers can express themselves without having to worry about that anything they write could end up at the customer (which I presume is the ultimate consumer of the changelog).
I also think there is a difference between a changelog and release notes with the former not being a replacement for the latter. For a good example how in my opinion useful release notes could look like see [2].
Apart from all of that git-cliff is an excellent implementation.
[1] https://www.conventionalcommits.org/en/v1.0.0/
[2] https://slack.com/intl/en-gb/release-notes/mac