Adapted from datafusion-comet's `dev/release/generate-changelog.py`:
walks the commit range between two refs, fetches the associated PRs
via the GitHub API, categorizes them by GitHub label and Conventional
Commit prefix (breaking / bug / perf / feat / docs / other), and emits
a markdown changelog with credits.
Only the project name (`apache/datafusion-java`) and the changelog
header ("DataFusion Java") are changed from the upstream script;
everything else is identical so future syncs are mechanical.
Usage:
cd dev/release
python3 -m venv venv && source venv/bin/activate
pip3 install -r requirements.txt
export GITHUB_TOKEN=<token>
python3 generate-changelog.py <prev-tag> HEAD <version> > ../../CHANGELOG.md
Which issue does this PR close?
Rationale for this change
The first datafusion-java release will need a changelog written between the previous tag and the release HEAD. The repo currently has no tooling for that, so a release manager would either hand-curate the list of merged PRs or copy a script from a sibling project. `datafusion-comet` already maintains a changelog generator that walks the git range, fetches PRs from the GitHub API, and categorizes them by GitHub label and Conventional Commit prefix. Adopting it here gives us the same output format and keeps future sync with comet mechanical.
What changes are included in this PR?
The script categorizes PRs by (in priority order):
Are these changes tested?
Smoke-tested locally against the last three merged PRs (`HEAD~3..HEAD`). The script correctly categorized two `feat:` PRs (#85, #77) as enhancements and one `chore:` PR (#87) as other, and emitted the expected markdown structure (ASF header, intro line with commit/contributor counts, per-bucket sections with author handles, credits block). The `resolve_ref` helper inherited from the upstream correctly normalizes `HEAD` to a SHA before the GitHub API call, so refs that resolve differently locally vs. on the default branch don't drift.
`python3 -c "import ast; ast.parse(open('dev/release/generate-changelog.py').read())"` is the syntactic check; the end-to-end test above covers the semantic behaviour.
Are there any user-facing changes?
No. Release-manager-facing tooling only.