chronicle VS git-cliff

we use https://github.com/anchore/chronicle to generate release notes in a changelog format using the issues and PRs from GitHub as the source of truth. In this way time well spent in the curation of issues and PRs (which is something we need to do anyway) means that we automatically get release notes for free. (disclaimer: I'm the author of chronicle)

The approach I like to take is to curate issues and PR with semantic titles and organize them by label ("bug", "enhancement", etc) or linking PRs to an already curated issue. This way automation can use these to generate the changlog for me on each release based on closed issues and unlinked PRs since the last release.

We wrote Chronicle to do that automation for us: https://github.com/anchore/chronicle .

The nice thing about this... since you typically curate issues during the development process anyway, if you're doing that right then you get a nice looking changlog for free! We use this approach with our core tools, Syft and Grype (some changlog examples: https://github.com/anchore/syft/releases/tag/v0.31.0 and https://github.com/anchore/grype/releases/tag/v0.26.1 ).

Always happy to hear new feature ideas and possible customizations for Chronicle (put in an issue and let's chat )!

git-cliff is a terminal tool that can generate changelog from the Git history by using conventional commits, as well as by using regex-powered parsers and you can even change the changelog template itself by using a configuration file. This tool is a great example of text parsing on the terminal and also uses clap_mangen which generates man pages. Useful for anyone who is serious about looking into making a production-ready terminal tool!

Solutions exist for this. Our company does this with git-cliff. Using conventional commits, any commit labeled with the subject "www" will appear in our public changelog.

This was primarily aimed to work with git-cliff to generate changelogs for GitHub releases, since tagging contributors would include them as contributors for the release, while also ensuring structured changelogs thanks to git-cliff. As of now, it requires a few extra steps to get it working with git-cliff, but the integration should be much better once the PR for post-processors is merged.

It's the first time I see someone combining gitmoji with conventional commits (I use the later now for all my project, to generate my changelogs automatically with with git-cliff.)