The current changelog is created automatically alongside a release, living only inside of said GitHub release. This current changelog, however, only lists the merged pull requests and categorizes them by their label, issues are ignored completely. This is problematic when we have multiple pull requests, all implementing small parts of a single feature (for example when we did the big UI overhaul, there were multiple pull requests all implementing a change). This single feature is oftentimes only documented in a single big or multiple smaller issues, with the pull requests only linking to said issue.
It can get very confusing for a user trying to understand what exactly changed in this new version. With a more verbose but organized changelog, it would be much clearer what changed or what bugs were fixed, because the issues are directly linked inside of the changelog.
For a changelog generator, I believe the best one for our use case is the GitHub-changelog-generator (see references) because it’s highly customizable and incorporates merged pull requests as well as closed issues into the changelog. It lets us add the generated changelog for a new version automatically to the GitHub release, removing the need for the current changelog generator altogether.
Checklist
[ ] Configure the generator to our needs
[ ] Create a script to generate the changelog
[ ] Create a workflow job that generates release notes
The current changelog is created automatically alongside a release, living only inside of said GitHub release. This current changelog, however, only lists the merged pull requests and categorizes them by their label, issues are ignored completely. This is problematic when we have multiple pull requests, all implementing small parts of a single feature (for example when we did the big UI overhaul, there were multiple pull requests all implementing a change). This single feature is oftentimes only documented in a single big or multiple smaller issues, with the pull requests only linking to said issue.
It can get very confusing for a user trying to understand what exactly changed in this new version. With a more verbose but organized changelog, it would be much clearer what changed or what bugs were fixed, because the issues are directly linked inside of the changelog.
For a changelog generator, I believe the best one for our use case is the GitHub-changelog-generator (see references) because it’s highly customizable and incorporates merged pull requests as well as closed issues into the changelog. It lets us add the generated changelog for a new version automatically to the GitHub release, removing the need for the current changelog generator altogether.
Checklist
References