The purpose of this document is to define the product stages as part of C* release life cycle and the expectations and commitments which exist at each stage. Scope of this document is limited to the lifecycle and stability of the product at large and not about any individual feature. The following stages have been identified and are described in detail below: Snapshot, Alpha, Beta, Release Candidate (RC), General Availability (GA), Maintenance, Deprecated, EOL.

Asterisks denote items that will require future work.

Note: We will maintain ongoing effort to ensure that the circleci testing suite as configured by the .circleci folder in the project root retains parity with ASF CI. See CASSANDRA-17930 - Getting issue details... STATUS for details on the initial push to achieve that parity.


  • A snapshot artifact is published for every commit to trunk. *
  • A retention window is associated with the snapshot artifacts.
  • Should not be used without collaboration/consultation with the developer community.
  • Will be discontinued / rewritten even if the idea validated.
  • Expectation that components of the core machinery may change, resulting in required code changes from the early adopters.  These breaking changes should be well-communicated.
  • As commits are made into trunk, contributors are encouraged to do extensive testing to ensure that no critical or severe bugs exist (e.g., data loss, consistency violations, incorrect responses to queries, etc). A clean test suite (unit, in-jvm and dtest) is mandatory with each commit.


  • Definition / Expectations:
    • From a user's perspective, the system is mostly “feature complete”
    • Usability is unpolished, and potentially changing on a frequent and regular basis.
    • Not ready for any user-impacting production usage, and recommended for development and testing only.
    • Should not be used without collaboration/consultation with the developer community.
    • A new major version is associated with the release, as it progresses from Alpha through EOL.
    • Interface and format changes may occur if necessary (i.e., a serious issue is identified during alpha testing) – but with strong preference to complete prior to alpha.
  • During this phase (actions):
    • Compatibility with tooling and automation
    • Compatibility with client libraries
    • Validation of newly added features
    • Smoke Test of existing features for catching any regression
    • Performance evaluation
    • Stability at different levels of workload (throughput)
    • An alpha release is made to have early adopters try it out and provide feedback in terms of the following
  • For Apache Cassandra Users
    • Forward compatibility will not be provided for future alpha builds
    • This release is recommended for test clusters which can take long downtimes and also a cluster data wipe.


  • Definition / Expectations:
    • Should be interface-stable, so that consumers do not have to incur any code changes on their end, as the release progresses from Alpha through EOL.
    • Carries the same major version from Alpha.
    • Either circleci ( as configured by the .circleci folder in project) or ASF CI ( can be considered as gatekeepers for a release. This requires ongoing effort to maintain parity between the test environments, however this should take place as part of us using circleci OR ASF CI as gatekeepers for commits.
    • For beta, we need a green run of circleci OR ASF CI to cut the release.
    • No new consistent regressions on ASF CI may exist when we cut the beta (i.e. don't make that worse).
    • We explicitly do not consider flaky tests on ASF CI infrastructure as beta release blockers (the vast majority are env specific as of 2022/10).
    • Following the first beta release, users can expect that SSTables generated by beta one or later will be fully compatible with future builds. Format changes will not be intentionally introduced, but may be if necessary to resolve issues identified during testing.
  • During this phase:
    • While product defects take precedence in prioritization in the project, issues with Beta are close behind that.
    • If there are no known bugs to be fixed before release, we promote to RC.
  • For Apache Cassandra Users
    • Forward compatibility for data will be provided for future beta releases
    • Rolling upgrades would not be provided for future beta releases
    • This release is recommended for test/QA clusters where short(order of minutes) downtime during upgrades is not an issue

Release Candidate (RC)

  • Definition / Expectations:
    • A release candidate build is legitimately a release candidate. The final release will be built from the same SHA as the final release candidate.
    • Three consecutive green runs of circleci OR of ASF CI are required to cut RC
  • During this phase:
    • If no release-blocking issues are identified within a brief incubation period, release is promoted to GA.
    • The intent of this period is to allow for the user community to fully exercise the release and flag potential release-blocking issues.
    • Smoke tests are executed for each RC build published.
    • If bugs are found, fixes are made and above step is repeated.
  • For Apache Cassandra Users
    • Forward compatibility for data and rolling upgrades will be provided for future rc  releases
    • This release is recommended for less critical production systems.

General Availability (GA)

  • Definition / Expectations:
    • This release is recommended for production deployment for all users.
    • Incremental fixes for post-GA issues identified will be included in patchlevel releases.
    • A new branch is created for the release with the new major version, limiting any new feature addition to the new release branch, with new feature development will continue to happen only on trunk.
    • Known issues may be screened to future fix versions.
  • For Apache Cassandra Users
    • This release is recommended for all production systems


  • New feature development has ceased, although bugs are still addressed with the urgency of a GA product.
  • Missing features from newer generation releases are back-ported on per - PMC vote basis.
  • Carries the same major version from Alpha.
  • Bug fix releases have associated new minor version.


  • Interim release while a replacement is slated for release.
  • Through a dev community voting process, EOL date is determined for this release.
  • Only security vulnerabilities and production-impacting bugs without workarounds are addressed.
  • Users actively encouraged to move away from the offering.


  • This is based on the EOL date determined as part of moving a release to “Deprecated” stage.
  • Product may begin malfunctioning at any time.
  • No support from the developer community.

Outstanding questions beyond the scope of this document

  1. What is the list of things a release should satisfy for it to be “Production Ready”.
  2. Compatibility between major versions - Content we have so far based on the feedback - Developer community will try not to make any backwards incompatible changes as much as possible, except in extreme cases like to ensure correctness. Introducing a backward incompatibility change needs dev community approval via voting [voting open for 48 hours].
  • No labels