Release Management Guide#
This page provides detailed information on the steps followed to perform a release. It can be used both as a guide to learn the ADBC release process and as a comprehensive checklist for the Release Manager when performing a release.
The Apache Arrow Release follows the guidelines defined at the Apache Software Foundation Release Policy.
Preparing for the release#
Some steps of the release require being a committer or a PMC member.
A GPG key in the Apache Web of Trust to sign artifacts. This will have to be cross signed by other Apache committers/PMC members. You must set your GPG key ID in
dev/release/.env.examplefor a template).
Configure Maven to publish artifacts to Apache repositories. You will need to setup a master password at
settings.xmlas specified on the Apache guide. It can be tested with the following command:
# You might need to export GPG_TTY=$(tty) to properly prompt for a passphrase mvn clean install -Papache-release
en_US.UTF-8locale. You can confirm available locales by
Install Conda with conda-forge, and create and activate the environment.
mamba create -n adbc -c conda-forge --file ci/conda_env_dev.txt
This will install two tools used in the release process:
commitizen(generates changelog from commit messages) and
gh(submit jobs/download artifacts).
Before creating a Release Candidate#
# Setup gpg agent for signing artifacts source dev/release/setup-gpg-agent.sh # Activate conda environment mamba activate adbc
Creating a Release Candidate#
These are the different steps that are required to create a Release Candidate.
For the initial Release Candidate, we will create a maintenance branch from master. Follow up Release Candidates will update the maintenance branch by cherry-picking specific commits.
We have implemented a Feature Freeze policy between Release Candidates. This means that, in general, we should only add bug fixes between Release Candidates. In rare cases, critical features can be added between Release Candidates, if there is community consensus.
Create or update the corresponding maintenance branch#
# Execute the following from an up to date master branch. # This will create a branch locally called maint-X.Y.Z. # X.Y.Z corresponds with the Major, Minor and Patch version number # of the release respectively. As an example 9.0.0 git branch maint-X.Y.Z # Push the maintenance branch to the remote repository git push -u apache maint-X.Y.Z
# First cherry-pick any commits by hand. git switch maint-X.Y.Z git cherry-pick ... # Push the updated maintenance branch to the remote repository git push -u apache maint-X.Y.Z
Create the Release Candidate branch from the updated maintenance branch#
# Start from the updated maintenance branch. git switch maint-X.Y.Z # The following script will create a branch for the Release Candidate, # place the necessary commits updating the version number and changelog, and then create a git tag # on OSX use gnu-sed with homebrew: brew install gnu-sed (and export to $PATH) # # <rc-number> starts at 0 and increments every time the Release Candidate is burned # so for the first RC this would be: dev/release/01-prepare.sh 4.0.0 5.0.0 0 dev/release/01-prepare.sh <version> <next-version> <rc-number> git push -u apache apache-arrow-adbc-<version>-rc<rc-number>
Build source and binaries and submit them#
# Build the source release tarball dev/release/02-source.sh <version> <rc-number> # Download the produced binaries, sign them, and add the # signatures to the GitHub release # # On macOS the only way I could get this to work was running "echo # "UPDATESTARTUPTTY" | gpg-connect-agent" before running this # comment otherwise I got errors referencing "ioctl" errors. dev/release/03-binary-sign.sh <version> <rc-number> # Sign and upload the Java artifacts # # Note that you need to press the "Close" button manually by Web interface # after you complete the script: # https://repository.apache.org/#stagingRepositories dev/release/04-java-upload.sh <version> <rc-number> # Sign and upload the deb/rpm packages and APT/Yum repositories # # This reuses release scripts in apache/arrow. So you need to # specify cloned apache/arrow directory. dev/release/05-linux-upload.sh <arrow-dir> <version> <rc-number> # Start verifications for binaries and wheels dev/release/06-binary-verify.sh <version> <rc-number>
Verify the Release#
Start the vote thread on firstname.lastname@example.org.
Voting and approval#
Start the vote thread on email@example.com and supply instructions for verifying the integrity of the release. Approval requires a net of 3 +1 votes from PMC members. A release cannot be vetoed.
After the release vote, we must undertake many tasks to update source artifacts, binary builds, and the Arrow website.
Be sure to go through on the following checklist:
Close the GitHub milestone/project
Add the new release to the Apache Reporter System
Add relevant release data for Arrow to Apache reporter.
Upload source release artifacts to Subversion
A PMC member must commit the source release artifacts to Subversion:
# dev/release/post-01-upload.sh 0.1.0 0 dev/release/post-01-upload.sh <version> <rc-number> git push --tag apache apache-arrow-adbc-<version>
Create the final GitHub release
A committer must create the final GitHub release:
# dev/release/post-02-binary.sh 0.1.0 0 dev/release/post-02-binary.sh <version> <rc-number>
This is done automatically when the tags are pushed. Please check that the nightly-website.yml workflow succeeded.
Upload wheels/sdist to PyPI
We use the twine tool to upload wheels to PyPI:
# dev/release/post-03-python.sh 10.0.0 dev/release/post-03-python.sh <version>
Publish Maven packages
Logon to the Apache repository: https://repository.apache.org/#stagingRepositories
Select the Arrow staging repository you created for RC:
Update tags for Go modules
# dev/release/post-04-go.sh 10.0.0 dev/release/post-04-go.sh <version>
Deploy APT/Yum repositories
# This reuses release scripts in apache/arrow. So you need to # specify cloned apache/arrow directory. # # dev/release/post-05-linux.sh ../arrow 10.0.0 0 dev/release/post-05-linux.sh <arrow-dir> <version> <rc-number>
Announce the new release
Publish release blog post
Remove old artifacts
# dev/release/post-07-bump-versions.sh 0.1.0 0.2.0 dev/release/post-07-bump-versions.sh <version> <next_version>