This is a good idea that would significantly simplify the release process in the long term, especially if the project keeps growing or if the release cadence slows down over time.
Describe the solution you have in mind
Add a PR template for the repository. The PR template should include a section "One line CHANGELOG entry" where contributors can provide a succinct (but not as succinct as a commit title or PR title?) description of their change. This description can then be used directly in the CHANGELOG (reviewers should validate it part of review). If the change doesn't impact users in any way, the section can be left empty (or one can use NONE).
When preparing a release, maintainers should have a script available to generate the CHANGELOG. The script would need to handle both minor version releases and patch version releases, by looking at the commit history. Commits need to be tied back to PRs somehow.
The generated CHANGELOG can be checked-in by the maintainer in-charge of the release (no different from what we do today).
Note that this may require more consistent labelling of PRs (notably the kind/* label and the release milestone) in order to generate high-quality release notes.
Describe how your solution impacts user flows
Users are not impacted.
Contributors are expected to generate the CHANGELOG entry for their contribution.
Release process is simplified for maintainers.
Additional context
K8s has tooling to auto-generate release notes. It is possible that we can re-use some of it with some small changes: https://github.com/kubernetes/release
Describe what you are trying to solve In https://github.com/antrea-io/antrea/pull/2230#discussion_r643608440, @tnqn suggested that we try to automate CHANGELOG-generation for each release, by collecting the relevant information from PR descriptions.
This is a good idea that would significantly simplify the release process in the long term, especially if the project keeps growing or if the release cadence slows down over time.
Describe the solution you have in mind
NONE
).Note that this may require more consistent labelling of PRs (notably the
kind/*
label and the release milestone) in order to generate high-quality release notes.Describe how your solution impacts user flows Users are not impacted. Contributors are expected to generate the CHANGELOG entry for their contribution. Release process is simplified for maintainers.
Additional context K8s has tooling to auto-generate release notes. It is possible that we can re-use some of it with some small changes: https://github.com/kubernetes/release