Release Process

The steps for Release Managers to create, vote and publish releases for Apache Cassandra.

While a committer can perform the initial steps of creating and calling a vote on a proposed release, only a PMC member can complete the process of publishing and announcing the release.


Background docs

A debian based linux OS is required to run the release steps from. Debian-based distros provide the required RPM, dpkg and repository management tools.

Create and publish your GPG key

To create a GPG key, follow the guidelines. The key must be 4096 bit RSA. Include your public key in:

Publish your GPG key in a PGP key server, such as MIT Keyserver.

Bintray account with access to Apache organisation

Publishing a successfully voted upon release requires bintray access to the Apache organisation. Please verify that you have a bintray account and the Apache organisation is listed here.

Create Release Artifacts

Any committer can perform the following steps to create and call a vote on a proposed release.

Check that there are no open urgent jira tickets currently being worked on. Also check with the PMC that there’s security vulnerabilities currently being worked on in private.’ Current project habit is to check the timing for a new release on the dev mailing lists.

Perform the Release

Run the following commands to generate and upload release artifacts, to the ASF nexus staging repository and dev distribution location:

cd ~/git
git clone
git clone

# Edit the variables at the top of the `` file
edit cassandra-builds/cassandra-release/

# Ensure your 4096 RSA key is the default secret key
edit ~/.gnupg/gpg.conf # update the `default-key` line
edit ~/.rpmmacros # update the `%gpg_name <key_id>` line

# Ensure DEBFULLNAME and DEBEMAIL is defined and exported, in the debian scripts configuration
edit ~/.devscripts

# The is run from the actual cassandra git checkout,
# on the branch/commit that we wish to tag for the tentative release along with version number to tag.
cd cassandra
git switch cassandra-<version-branch>

# The following cuts the release artifacts (including deb and rpm packages) and deploy to staging environments
../cassandra-builds/cassandra-release/ -v <version>

Follow the prompts.

If building the deb or rpm packages fail, those steps can be repeated individually using the -d and -r flags, respectively.

Call for a Vote

Fill out the following email template and send to the dev mailing list:

I propose the following artifacts for release as <version>.

sha1: <git-sha>



Staging repository:<nexus-id>/

The distribution packages are available here:${version}/

The vote will be open for 72 hours (longer if needed).

[1]: (CHANGES.txt);a=blob_plain;f=CHANGES.txt;hb=<version>-tentative
[2]: (NEWS.txt);a=blob_plain;f=NEWS.txt;hb=<version>-tentative

Post-vote operations

Any PMC member can perform the following steps to formalize and publish a successfully voted release.

Publish Artifacts

Run the following commands to publish the voted release artifacts:

cd ~/git
# edit the variables at the top of the `` file
edit cassandra-builds/cassandra-release/

# After cloning cassandra-builds repo, `` is run from the actual cassandra git checkout,
# on the tentative release tag that we wish to tag for the final release version number tag.
cd ~/git/cassandra/
git checkout <version>-tentative
../cassandra-builds/cassandra-release/ -v <version>

If successful, take note of the email text output which can be used in the next section “Send Release Announcement”. The output will also list the next steps that are required.

Promote Nexus Repository

  • Login to Nexus repository again.
  • Click on “Staging” and then on the repository with id “cassandra-staging”.
  • Find your closed staging repository, right click on it and choose “Promote”.
  • Select the “Releases” repository and click “Promote”.
  • Next click on “Repositories”, select the “Releases” repository and validate that your artifacts exist as you expect them.

Publish the Bintray Uploaded Distribution Packages

Log into bintray and publish the uploaded artifacts.

Update and Publish Website

See docs for building and publishing the website.

Also update the CQL doc if appropriate.

Release version in JIRA

Release the JIRA version.

  • In JIRA go to the version that you want to release and release it.
  • Create a new version, if it has not been done before.

Update to Next Development Version

Update the codebase to point to the next development version:

cd ~/git/cassandra/
git checkout cassandra-<version-branch>
edit build.xml          # update `<property name="base.version" value="…"/> `
edit debian/changelog   # add entry for new version
edit CHANGES.txt        # add entry for new version, move up any entries that were added after the release was cut and staged
git commit -m "Increment version to <next-version>" build.xml debian/changelog CHANGES.txt

# …and forward merge and push per normal procedure

Send Release Announcement

Fill out the following email template and send to both user and dev mailing lists:

The Cassandra team is pleased to announce the release of Apache Cassandra version <version>.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising

Downloads of source and binary distributions are listed in our download

This version is <the first|a bug fix> release[1] on the <version-base> series. As always,
please pay attention to the release notes[2] and let us know[3] if you
were to encounter any problem.


[1]: (CHANGES.txt);a=blob_plain;f=CHANGES.txt;hb=<version>
[2]: (NEWS.txt);a=blob_plain;f=NEWS.txt;hb=<version>

Update Slack Cassandra topic

Update topic in cassandra Slack room
/topic | Latest releases: 3.11.4, 3.0.18, 2.2.14, 2.1.21 | ask, don’t ask to ask

Tweet from @Cassandra

Tweet the new release, from the @Cassandra account

Delete Old Releases

As described in When to Archive.

An example of removing old releases:

svn rm<previous_version>