[ratherbefuddled]

Of course not. How else would you do it?

[cyphar]

Have a dedicated changelog you maintain[1].

Patch descriptions are for developers, not for users -- aside from the fact they're the wrong granularity (no user cares if it took 20 patches and three PR cycles to implement a feature), they should contain details and justification that are only useful for future debugging or for review purposes (which users also don't care about). And if you have a bugfix for a previously-merged patch that hasn't yet been released, why would you include the bugfix in the changelog?

Yes, with the right format and discipline you could generate reasonable changelogs from your commit logs -- but at that point it's so much easier to just keep a CHANGELOG.md.

[1]: https://keepachangelog.com/en/1.0.0/

[ratherbefuddled]

In my experience its unlikely this will be complete or accurate on any project maintained by a team of more than a couple of people.

Common practice for a long time has been to include a ticket id in the commit and then use a script to pull all the ticket ids from the commits since the last release and pull the (user facing) release note info from ticketing system.

Of course you don't want commit messages going to users but you don't want to rely on handcrafted lists either. Particularly when a release as far as a customer is concerned is infrequent and contains changes from many repos.

[dchest]

Make a human read the commit history (or tickets) and summarize changes in the language useful for users, not for developers.

[Vinnl]

Exactly. I can read commit messages myself, but there's a lot of stuff in there that's not relevant to me as a consumer - e.g. refactorings, cleanups, etc.

[adrianN]

I'm sure the human appreciates some help from a script that can parse metadata in the commit messages.