Hello, I also support and vote for semantic versioning (which is still there) and conventional commits. I don't know Cliff. Because the CHANGELOG is very important I won't like to have a full automatic at this point. Tools collecting the commits and create a draft(!) of a CHANGELOG out of it which can be checked and corrected by a human being maintainer would be nice. But I would simply copy and paste a "git log" output and edit that. Oh yeah, release dates would be great. I often miss them in other projects. I'm quit experienced in git and git project management. The "problem" about multiple commit messages in a PR is not a "problem". Michael as the merger can squash them in the GitHub web front-end. How to handle git branches etc is up to the maintainers with commit/merge rights and not a problem of a usual contributor opening a PR. IMHO it is the responsibility of the merging maintainer to commit a PR with a "good" commit message in a "good" branch. The topic keyword here is "git branching models" (sometimes synonym used "git workflow"). This topic is to early and will come up, when Germar decided about the handover of rights. Kind Christian