Tags: apache/arrow-rs
Tags
Update version to 59.2.0, update changelog generation to git-cliff (#… …10451) Note (from @alamb): This PR contains both: 1. Update the version to 59.2.0 2. Add 59.2.0 CHANGELOG; Rendered preview: https://github.com/Jefffrey/arrow-rs/blob/better-changelog-generation/CHANGELOG.md 3. Update dev/release/readme.md to use `git-cliff` rather than changelog_generator 4. Remove other script `git-cliff` was a much nicer experience than the changelog generator (specifically it ran much faster) --- - Closes #9332 - Part of #9879 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](github-changelog-generator/github-changelog-generator#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. # Speed Oh also its blazing fast 😃 (well compared to old approach) ```sh arrow-rs (better-changelog-generation)$ time git-cliff --tag 59.2.0 --unreleased --output EXAMPLE_CHANGELOG.md WARN git_cliff_core::changelog > process_commits: 1 commit(s) were skipped due to field error(s) (run with `-vv` for details) ________________________________________________________ Executed in 31.60 secs fish external usr time 4.35 secs 0.27 millis 4.35 secs sys time 3.75 secs 1.49 millis 3.75 secs ``` - that warning is only popping because its from the commit of this branch, aka not a PR squash commit # Further work Need to update release instructions if going with this approach; also want to test out patch releases (aka test when we're not generating for commits off main) --------- Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
Update version to 59.2.0, update changelog generation to git-cliff (#… …10451) Note (from @alamb): This PR contains both: 1. Update the version to 59.2.0 2. Add 59.2.0 CHANGELOG; Rendered preview: https://github.com/Jefffrey/arrow-rs/blob/better-changelog-generation/CHANGELOG.md 3. Update dev/release/readme.md to use `git-cliff` rather than changelog_generator 4. Remove other script `git-cliff` was a much nicer experience than the changelog generator (specifically it ran much faster) --- - Closes #9332 - Part of #9879 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](github-changelog-generator/github-changelog-generator#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. # Speed Oh also its blazing fast 😃 (well compared to old approach) ```sh arrow-rs (better-changelog-generation)$ time git-cliff --tag 59.2.0 --unreleased --output EXAMPLE_CHANGELOG.md WARN git_cliff_core::changelog > process_commits: 1 commit(s) were skipped due to field error(s) (run with `-vv` for details) ________________________________________________________ Executed in 31.60 secs fish external usr time 4.35 secs 0.27 millis 4.35 secs sys time 3.75 secs 1.49 millis 3.75 secs ``` - that warning is only popping because its from the commit of this branch, aka not a PR squash commit # Further work Need to update release instructions if going with this approach; also want to test out patch releases (aka test when we're not generating for commits off main) --------- Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
[58_maintenance] Update changelog for #10371 (#10372) ## Which issue does this PR close? - part of #10349 Follow up to #10367, which prepared the `58.4.0` changelog. PR #10371 was subsequently merged to `58_maintenance`, so this PR adds it to the `58.4.0` changelog section. ## Rationale for this change Keep `CHANGELOG.md` on `58_maintenance` in sync with the commits actually on the branch prior to cutting the `58.4.0` release. ## What changes are included in this PR? Adds a changelog entry for #10371.
[58_maintenance] Update changelog for #10371 (#10372) ## Which issue does this PR close? - part of #10349 Follow up to #10367, which prepared the `58.4.0` changelog. PR #10371 was subsequently merged to `58_maintenance`, so this PR adds it to the `58.4.0` changelog section. ## Rationale for this change Keep `CHANGELOG.md` on `58_maintenance` in sync with the commits actually on the branch prior to cutting the `58.4.0` release. ## What changes are included in this PR? Adds a changelog entry for #10371.
Prepare for `59.1.0` release (#10274) # Which issue does this PR close? - Part of #9878 # Rationale for this change This prepares for the `59.1.0` (minor) release of the Rust Arrow / Parquet crates. # What changes are included in this PR? 1. Update version to `59.1.0` 2. Update CHANGELOG. See rendered preview here: https://github.com/alamb/arrow-rs/blob/release-59.1.0/CHANGELOG.md # Are these changes tested? By CI # Are there any user-facing changes? yes
Prepare for `59.1.0` release (#10274) # Which issue does this PR close? - Part of #9878 # Rationale for this change This prepares for the `59.1.0` (minor) release of the Rust Arrow / Parquet crates. # What changes are included in this PR? 1. Update version to `59.1.0` 2. Update CHANGELOG. See rendered preview here: https://github.com/alamb/arrow-rs/blob/release-59.1.0/CHANGELOG.md # Are these changes tested? By CI # Are there any user-facing changes? yes
Add test for `parquet-testing/bad_data/ARROW-GH-47662.parquet` (#10077) # Which issue does this PR close? - Issue raised in #9110 # Rationale for this change Add a "bad_data" test for newly added file in parquet-testing # What changes are included in this PR? Adds a new test so the `bad_data` unit test doesn't fail. # Are these changes tested? Yes # Are there any user-facing changes? No, only tests
Add test for `parquet-testing/bad_data/ARROW-GH-47662.parquet` (#10077) # Which issue does this PR close? - Issue raised in #9110 # Rationale for this change Add a "bad_data" test for newly added file in parquet-testing # What changes are included in this PR? Adds a new test so the `bad_data` unit test doesn't fail. # Are these changes tested? Yes # Are there any user-facing changes? No, only tests
Prepare for `58.3.0` release (#9893) # Which issue does this PR close? - Part of #9859 # Rationale for this change Even though we just did a release from 58, I want to get a release out that has these changes: - #9872 - #9813 # What changes are included in this PR? 1. Update version to 58.3.0 2. Update CHANGELOG. See Rendered preview here: https://github.com/alamb/arrow-rs/blob/alamb/prepare_58.3.0/CHANGELOG.md # Are these changes tested? By CI # Are there any user-facing changes? yes
Prepare for `58.3.0` release (#9893) # Which issue does this PR close? - Part of #9859 # Rationale for this change Even though we just did a release from 58, I want to get a release out that has these changes: - #9872 - #9813 # What changes are included in this PR? 1. Update version to 58.3.0 2. Update CHANGELOG. See Rendered preview here: https://github.com/alamb/arrow-rs/blob/alamb/prepare_58.3.0/CHANGELOG.md # Are these changes tested? By CI # Are there any user-facing changes? yes
PreviousNext