Update version to 59.2.0, update changelog generation to git-cliff

[Jefffrey]

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 Changelog generation is complicated / takes a long time #9332
• Part of Release arrow-rs / parquet Minor version 59.2.0 (July 2026) #9879

Testing out git-cliff 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

cargo install git-cliff
brew install git-cliff

• See their installation guide

Then we need to ensure we have the tags locally:

# 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:

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:

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 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)

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)

[Jefffrey]

@alamb we could try test this out for upcoming release? 👀

I haven't updated the release instructions, but it would essentially cut out the need for running existing update changelog script and the label issues script too

Edit: if we do wanna use this for 59.2.0 release I can go in and label a few more PRs to get a better changelog

[alamb]

Yes, I would love to try this out. I personally think the github changelog generator is quite long in the tooth and I would welcome this change.

[alamb]

Another potential option would be to port the datafusion generate-changelog script: https://github.com/apache/datafusion/blob/main/dev/release/generate-changelog.py

However I think it would be good to try another tool and see how it goes

[Jefffrey]

Regarding the changelog file, do we prefer keeping this approach of having latest changelog in CHANGELOG.md and historical in CHANGELOG-old.md or would we want them combined? If we combine them then we can use the --prepend feature to completely automate it, otherwise I think we'd still need a manual step to copy existing CHANGELOG.md into CHANGELOG-old.md before generating new CHANGELOG.md.

• I noticed there was Move changelog archive to CHANGELOG-old.md #1759 for the purpose of simplifying release

Though one thing to keep in mind is having a single big CHANGELOG.md might be slow to open for some people

Another potential option would be to port the datafusion generate-changelog script: https://github.com/apache/datafusion/blob/main/dev/release/generate-changelog.py

I think git-cliff can achieve almost the same things as this script, with the exception of the contributor stats at the end (though we don't do that here). It might be possible to get that to work if we want in git-cliff.

[alamb]

Though one thing to keep in mind is having a single big CHANGELOG.md might be slow to open for some people

Yeah, the total changelog for arrow-rs is now pretty large (there is lots of good stuff in there https://github.com/apache/arrow-rs/blob/main/CHANGELOG-old.md)

[Jefffrey]

I did a quick test where I imitated a 58.5.0 release, and it seems to generate changelog fine

• Checked out 58.4.0 to local branch
• Created some commits
• Ran command
• Changelog showed only those new commits I created, didn't get confused with branches

So looks like the use_branch_tags = true option works quite well in ensuring it picks the right tag to consider as latest release you want to compare to (so long as you ensure you're on the same branch as previous release, aka 58_maintenance branch)

[Jefffrey]

I noticed we never had an explicit step for this? I don't think our existing changelog script did this either

[Jefffrey]

Another potential option would be to port the datafusion generate-changelog script: https://github.com/apache/datafusion/blob/main/dev/release/generate-changelog.py

Out of curiosity, how long on average does it take to run the DataFusion version? (Though DataFusion does have more commits per release, at least for major ones) @alamb

[alamb]

I am starting to test this out for the 59.2.0 release. As long as I am able to replicate the results my plan is to update + merge this PR

[alamb]

This now looks great to me -- but since I made some changes to it since @Jefffrey say, it is probably good to get another set of eyes on the change too before we merge it

[alamb]

I changed this to use remote.pr_title first and then fall back to commit message.