Operators Developers Contributors Reference
Sidebar updates per section — preview limitation
Apache Cassandra

Release Process

The Apache Cassandra release process follows ASF release policy. Releases are managed by committers and PMC members.

Release Overview

A Cassandra release involves:

  1. A release branch is cut from the development branch (e.g., cassandra-6.0 from trunk)

  2. Release artifacts are built, signed, and staged

  3. The release is voted on by the PMC via the dev mailing list

  4. After a successful vote, artifacts are published to Apache mirrors

Release Cadence

Release cadence is branch-driven rather than calendar-driven. The PMC cuts a release when a branch is ready, and point releases are scheduled when urgent fixes, regressions, or security issues justify one. As a contributor, assume release timing is decided by committers and the PMC, not by the presence of a single merged patch.

Release Branches

Each major and minor version has a corresponding branch:

  • trunk — active development for the next major release

  • cassandra-5.0 — maintenance branch for the 5.0.x release line

  • cassandra-4.1 — maintenance branch for the 4.1.x release line

Bug fixes merge forward through branches in order (see How to Commit).

This page provides an overview of the release process. The detailed release procedure, including signing keys, staging repository setup, and vote mechanics, requires committer-level access and is documented on the Apache Cassandra wiki.