3 ms·
>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 does
by tjoff 2y ago
>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.
- weinzierl 2y agoSome projects make it work, see the ratatui.rs example in another comment.
- tjoff 2y agoratatui.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). A better example, in my eyes, is teamcity. https://www.jetbrains.com/help/teamcity/what-s-new-in-teamcity.html https://www.jetbrains.com/help/teamcity/what-s-new-in-teamci... A curated overview that actually explains the change rather than just states a difference. They also have a similar view of fixed tickets: https://www.jetbrains.com/help/teamcity/teamcity-2024-03-release-notes.html https://www.jetbrains.com/help/teamcity/teamcity-2024-03-rel... 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.