Jefffrey opened a new pull request, #10451: URL: https://github.com/apache/arrow-rs/pull/10451
- Closes #9332 Testing out [git-cliff](https://git-cliff.org/) for generating our changelogs. In this PR I've included the config file, as well as an example changelog for upcoming 59.2.0 release. To install `git-cliff` can either cargo install or do via brew ```sh cargo install git-cliff brew install git-cliff ``` - See their [installation guide](https://git-cliff.org/docs/installation/) Then we need to ensure we have the tags locally: ```sh # If remote for the apache remote is named differently ensure swap to the name here git fetch origin --tags ``` - `git-cliff` operates via checking the commits since latest tag, so if we don't locally have the tags it'll generate a changelog since the start of time 🙂 Then run command: ```sh git-cliff --tag 59.2.0 --unreleased --output EXAMPLE_CHANGELOG.md ``` - Set github token via `GITHUB_TOKEN` environment variable, or can add to command via `--github-token` - This will create a changelog for all commits since the last non-rc tag on this branch, named `59.2.0` (we change this for each release), into a separate file Then can see what the generated changelog is like in this PR. `git-cliff` also supports prepending onto an existing changelog, in which case it removes the header (specified in the config), prepends new body, then re-adds the header: ```sh git-cliff --tag 59.2.0 --unreleased --prepend CHANGELOG.md ``` - You could even have both `--output` and `--prepend` so long as they don't point to the same file # On categorization `git-cliff` looks only at PRs; it ignores issues. I prefer this approach as it makes it more clear which code we actually shipped. There was also an issue with our previous approach in that [`github-changelog-generator` didn't ignore issues closed as not planned/duplicate](https://github.com/github-changelog-generator/github-changelog-generator/issues/1038) which can add noise to the changelog. By focusing only on PRs we don't need to worry about this, and we also don't need to bother labeling issues from their PRs anymore. However, we need to ensure our PRs have good labeling. This can come from maintainers adding labels, or having workflows to do some of this automation. For example we could: - Use a workflow to copy the bug/enhancement tag from an issue to the linked PR: https://github.com/michalvankodev/copy-issue-labels - Enhance existing labeling workflow, such as adding `development-process` to PRs that only touch benches/tests For now I've been going around to some PRs and adding labels to get some better categorization in this example. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
