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.
Currently (May 2022) there are five relevant branches to be familiar with:
- cassandra-3.0 (3.0)
- cassandra-3.11 (3.11)
- cassandra-4.0 (latest GA)
- cassandra-4.1 (frozen, pending release)
- trunk (next release)
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.
Versioning and targeting:
We use semver for our versioning as follows:
- 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.
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.