Release Verification Guide

Audience: Committers and interested contributors.

This guide walks you through the process of verifying a staged Apache Polaris release candidate.

Please keep the ASF Release Policy, especially the section on “Owned and Controlled Hardware,” in mind: Strictly speaking, releases must be verified on hardware owned and controlled by the committer.

Verifying a (staged) release of an Apache project has to follow a bunch of tasks, which can be grouped into tasks that can be automated and those that need human intervention. Polaris provides a tool to automate the tasks that can be automated.

Tasks that are automated:

Tasks that need human attention:

Other tests:

Imply good intent! Although the release manager is responsible for producing a “proper” release, mistakes can and will happen. The Polaris project is committed to providing reproducible builds as an essential building block of Apache trusted releases. The project depends on frameworks which also strive to provide reproducible builds, but not all these frameworks can provide fully reproducible builds yet. The Polaris project’s release verification tool will therefore report some issues that are currently expected. See below for details.

After you have completed the verification of the release candidate, respond to the release vote email, detailing the checks and tests you performed, and providing a summary of their outcomes. Remember to include your vote (+1/0/-1) and whether it’s “binding.” A -1 vote requires a technical justification. As a (P)PMC member, your vote is “binding,” all other votes are “non-binding.”

Verifying a release candidate

Instead of performing all mentioned steps manually, you can leverage the script tools/verify-release/verify-release.sh, available in the main repository, to perform the automatable tasks. The script is intended to be run on Linux or macOS.

Verifying the script

Verifying a release using any kind of automation, like this script, requires “trust” into the automation. It is therefore recommended to verify the script before running it on a release candidate. You can inspect it by looking at the source code before running it. The link to the Raw file must be the same as the one used in the command below to run the script.

Running the script

Run the most recent version of the script using the following command:

bash <(curl \
  -s https://raw.githubusercontent.com/apache/polaris/refs/heads/main/tools/verify-release/verify-release.sh) \
  --help

The tool is intended for Polaris versions 1.3 and newer. The tool may report issues, see below for details.

That script requires a couple of tools installed and will check that those are available and report those that need to be installed.

To run the script, you need the following pieces of information from the release-vote email:

Example (values taken from the 1.2.0-rc2 release)

bash <(curl \
  --silent https://raw.githubusercontent.com/apache/polaris/refs/heads/main/tools/verify-release/verify-release.sh) \
  --git-sha 354a5ef6b337bf690b7a12fefe2c984e2139b029 \
  --version 1.3.0-incubating-rc0 \
  --maven-repo-id 1033

Same example, but using the short option names:

bash <(curl \
  -s https://raw.githubusercontent.com/apache/polaris/refs/heads/main/tools/verify-release/verify-release.sh) \
  -s 354a5ef6b337bf690b7a12fefe2c984e2139b029 \
  -v 1.3.0-incubating-rc0 \
  -m 1033

The verification script creates a temporary directory that will eventually contain a fresh Git clone, all downloaded and all built artifacts. This temporary directory is deleted after the script has finished. To keep the temporary directory around, you can use the --keep-temp-dir (-k) option.

A log file, the name matches the pattern polaris-release-verify-*.log, will be created and contain detailed information about the identified issues reported on the console.

Note: The script is maintained in the Polaris source tree in the /tools/verify-release directory.

Verifications performed by the tool

After some startup checks, the tool emits some information about the release candidate. For example:

Verifying staged release
========================

Git tag:           apache-polaris-1.3.0-incubating-rc0
Git sha:           354a5ef6b337bf690b7a12fefe2c984e2139b029
Version:           1.3.0-incubating
RC:                0
Maven repo URL:    https://repository.apache.org/content/repositories/orgapachepolaris-1033/
Main dist URL:     https://dist.apache.org/repos/dist/dev/incubator/polaris/1.3.0-incubating
Helm chart URL:    https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart/1.3.0-incubating
Verify directory:  /tmp/polaris-release-verify-2025-10-23-14-22-31-HPmmiybzk

A verbose log containing the identified issues will be available here:
    .../polaris-release-verify-2025-10-23-14-22-31.log

After that, release candidate verification starts immediately, performing the following operations:

  1. Create gpg keyring for signature verification from the project’s KEYS file.
  2. Clone the Git repository directly from GitHub.
  3. Verifies that the Git tag corresponds to the provided Git SHA
  4. Verifies that the mandatory files are present in the source tree
  5. Helm chart GPG signature and checksum checks
  6. Source tarball and binary artifacts GPG signature and checksum checks
  7. Build Polaris from the Git commit/tag
  8. Compares that the list of Maven artifacts produced by the build matches those in the Nexus staging repository.
  9. Compares the individual Maven artifacts of the local build with the ones in the Nexus staging repository.
  10. Compares the main binary distribution artifacts for Polaris server and Polaris admin tool.
  11. Compares the locally built Helm chart with the one in the staging repository.

Found issues are reported on the console in red.

Details for each reported issue will be reported in the log file, depending on the issue and file type. The intent is to provide as much information as possible to eventually fix a reproducible build issue.

Note: GPG signatures are verified only against the project’s KEYS file.

If the script finds no issues, the temporary verification directory is deleted by default. You can keep it around by using the --keep-temp-dir (-k) option. Remember to delete it manually when you’re done.

Reproducible builds

A build is reproducible if the built artifacts are identical for every build on every machine from the same source.

The Apache Polaris build is currently mostly reproducible, with some release-version specific exceptions.

References:

Exceptions for all Apache Polaris versions

Pending on full support for reproducible builds in Quarkus:

Helm packages are not binary reproducible yet. See helm-package notes on this page.