I prefer a manual changelog over generating one from conventional
commit message format. First of all it does not require you to follow
detailed conventions when naming your commits. Furthermore, a human can
summarize changes in a better way than a software tool.
Ideally the repository will include tags for all released versions in
the future (e.g. v0.0.8 for the next release). Then these tags can be
used in the CHANGELOG instead of commit IDs.
(You could also tag the old releases that were made in the past.)
For reasons to keep a changelog, see https://blog.dbrgn.ch/2015/12/1/rust-crates-keep-a-changelog/.
I prefer a manual changelog over generating one from conventional commit message format. First of all it does not require you to follow detailed conventions when naming your commits. Furthermore, a human can summarize changes in a better way than a software tool.
Ideally the repository will include tags for all released versions in the future (e.g.
v0.0.8
for the next release). Then these tags can be used in the CHANGELOG instead of commit IDs. (You could also tag the old releases that were made in the past.)