Note: consider merging this into and renaming the Release Lifecycle wiki article
We support three releases at any given time; the latest GA version and two long-term releases back (see site here for current versions). Our ticket targeting strategy differs based on which version you're targeting:
Patch types and targeting:
As you work on patches in JIRA you need to determine which branch to apply your patch to.
Active Branches
Currently (August 2023) there are six relevant branches to be familiar with:
- cassandra-3.0 (3.0)
- cassandra-3.11 (3.11)
- cassandra-4.0 (4.0)
- cassandra-4.1 (latest GA)
- cassandra-5.0 (frozen w/waiver for Accord, Transactional Metadata work, and Vector search)
- trunk (next release)
Where to apply patches
When working on a ticket, use the following guideline to determine which branch to apply it to (Note: See How To Commit for details on the commit and merge process)
- Bugfix: apply to oldest applicable LTS and merge up through latest GA to trunk
- In the event you need to make changes on the merge commit, merge with -s ours and revise the commit via --amend
- Improvement: apply to trunk only (next release)
- Note: refactoring and removing dead code qualifies as an Improvement; our priority is stability on GA lines
- New Feature: apply to trunk only (next release)
Our priority is to keep the 2 LTS releases and latest GA stable while releasing new "latest GA" on a cadence that provides new improvements and functionality to users soon enough to be valuable and relevant.
Merge path examples
So for example, if you have a bugfix that applies to all branches, your apply and merge path would be:
cassandra-3.0 (apply) → cassandra-3.11 → cassandra-4.0 → cassandra-4.1 → cassandra-5.0 → trunk
A new feature or improvement would apply trunk only:
trunk (apply)
Versioning and targeting:
We use semver for our versioning as follows:
MAJOR.MINOR.PATCH-SUFFIX
For example:
- 4.0.1: patch release on 4.0
- 3.11.5: patch release on 3.11 line
- 3.0: major release of 3.0 w/API breaking changes
- 4.1.0-SNAPSHOT: latest nightly snapshot for 4.1.0
When making a change to Cassandra, it's critical to understand when you're making breaking changes to APIs and protocols. Any changes necessitating changes to anything referenced in doc/native_protocol_vN.spec, (TODO: ENUMERATE VARIOUS ENUMS / CLASSES / ETC related to binary protocol here) will need to target the next major version. At this time (Jan 2022, working on version 4.1) we have not yet branched for new API breaking changes that would necessitate a 5.0 release.
Hotfix Releases:
For hotfix releases (security, data loss, other critical issues), we create a branch based off the last released tag and apply only the minimal diff to that branch in order to address whatever prompted the need for the hotfix. The goal of this process is to provide as little change as is necessary to our users to upgrade their clusters to patch out these types of issues.