Automatic CHANGELOG or release generation (via semantic release?)

[JuroOravec]

Recently I was updating my project where I use django-components from v0.31 to v0.61.

To ensure I understand the things that've changed, I went over names of commits between the two releases to get an idea. The reason is that while some changes are documented in the Release notes section of the README, not all of changes are captured there (e.g. I didn't include the changes in v0.60 there - should have I done that?).

So I'd like to discuss here options for better documentation of changes between releases.

---

My thoughts:

Coming from JS world, I've used semantic-release in the past, which can be used also to generate e.g. changelogs.

The idea behind semantic-release is that commit messages conform to specific standard (it uses conventional commits if I remember correctly), e.g.

feat!: this commit introduces a breaking change feature

And then, preferably in CI, the semantic-release CLI is run. It looks up all commits since the last release/tag, and checks what form the commit messages had, to decide whether to increase version by major, minor, or patch. And then it can automatically bumps package version or generate changelog with the changes.

Beside (or instead) of a CHANGELOG file, the changes can be managed as Github releases.

There is a Python implementation of semantic-release which seems to handle it all:

• Automatic release
• Changelog generation
• Github release generation

[EmilStenstrom]

Makes sense.

Something to consider here is that there are a few drive-by commits in this repo, by people that want to help but doesn't want to jump through hoops to contribute. If the commit format just applies to the merge commit (that we generate), things would still work for drive-bys. Does it?