Skip to content

release

Directory actions

More options

Directory actions

More options

Latest commit

 

History

History

release

README.md

Release

Overview

  1. Test the revision to be released
  2. Bump version for new release (detailed later)
  3. Prepare RC and vote (detailed later)
  4. Publish (detailed later)
  5. Announce the new release on the mailing list (detailed later)
  6. Announce the new release on social media (detailed later)

Prepare release environment

This step is needed only when you act as a release manager the first time.

We use the following variables in multiple steps:

  • GH_TOKEN: GitHub personal access token to automate GitHub related operations
  • GPG_KEY_ID: PGP key ID that is used for signing official artifacts by GnuPG

We use dev/release/.env to share these variables in multiple steps. You can use dev/release/.env.example as a template:

$ cp dev/release/.env{.example,}
$ chmod go-r dev/release/.env
$ editor dev/release/.env

See https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens how to prepare GitHub personal access token for GH_TOKEN.

Note that you also need to install gh command because our scripts use gh command to use GitHub API. See https://github.com/cli/cli#installation how to install gh command.

If you don't have a PGP key for GPG_KEY_ID, see https://infra.apache.org/release-signing.html#genegrate how to generate your PGP key.

Your PGP key must be registered to the followings:

See the header comment of them how to add a PGP key.

Apache arrow committers can update them by Subversion client with their ASF account. e.g.:

$ svn co https://dist.apache.org/repos/dist/dev/arrow
$ cd arrow
$ head KEYS
(This shows how to update KEYS)
$ svn ci KEYS

Bump version for new release

Open a PR that bumps version for new release. We must follow Semantic Versioning. For example, we must bump major version when we have any incompatible changes.

You can proceed to the next step once we merge the opened PR.

Prepare RC and vote

You can use dev/release/release_rc.sh.

Requirements to run release_rc.sh:

  • You must be an Apache Arrow committer or PMC member
  • You must prepare your PGP key for signing

Run dev/release/release_rc.sh on a working copy of git@github.com:apache/arrow-js not your fork:

$ git clone git@github.com:apache/arrow-js.git
$ cd arrow-js
$ dev/release/release_rc.sh ${RC}
(Send a vote email to dev@arrow.apache.org.
 You can use a draft shown by release_rc.sh for the email.)

Here is an example to release RC1:

$ dev/release/release_rc.sh 1

The argument of release_rc.sh is the RC number. If RC1 has a problem, we'll increment the RC number such as RC2, RC3 and so on.

Publish

We need to do the followings to publish a new release:

Run dev/release/release.sh on a working copy of git@github.com:apache/arrow-js not your fork to publish the source archive to apache.org:

$ dev/release/release.sh ${RC}

Here is an example to release RC1:

$ dev/release/release.sh 1

Add the release to ASF's report database via Apache Committee Report Helper.

Send an email to "announce@apache.org" from your Apache email, Cc'ing dev@arrow.apache.org/user@arrow.apache.org. You can use the draft email generated by dev/release/release.sh.

Announce the new release on social media

Make a post on our BlueSky and LinkedIn accounts. (Ask your fellow PMC members for access if need be, or ask a PMC member to make the post on your behalf.) The post should link to the blog post. See example BlueSky post and example LinkedIn post.

Verify

We have a script to verify a RC.

You must install the following commands to use the script:

  • curl
  • gpg
  • shasum or sha256sum/sha512sum
  • tar

To verify a RC, run the following command line:

$ dev/release/verify_rc.sh ${VERSION} ${RC}

Here is an example to verify the release 20.0.0 RC1:

$ dev/release/verify_rc.sh 20.0.0 1

If the verification is successful, the message RC looks good! is shown.