Cassandra separates release cadence from stabilization

A predictable development schedule does not require declaring unfinished software ready for production on a fixed date. Cassandra's release cadence policy, published on 1 December, separates those decisions. It targets annual release branching and quarterly alpha artifacts while leaving stabilization to its own process.

Josh McKenzie's publication message records that the vote passed and the agreed text was added to the wiki. The policy is therefore a documented process decision. It gives users and contributors a common reference for interpreting future artifacts without turning a target date into a quality certificate.

Cassandra interests me for workloads that need its distributed availability. Predictable evaluation opportunities matter in that setting because adopting a database feature includes qualification outside the project's own tests. My preference is for a schedule that makes that work easier to organize while keeping the production-readiness decision explicit.

Branching has a schedule and stabilization has criteria

The policy targets an April release branch and a first beta shortly after the freeze. Later betas, release candidates and GA follow readiness criteria rather than a fixed progression through the calendar. Adjacent major lines can stabilize independently.

Quarterly alphas target July, October and January. They come from tags rather than new maintained branches and receive no support or alpha backports. Subprojects may follow the same rhythm but can skip an unproductive quarter after discussion. The stated dates are aspirations for a volunteer project.

This is a useful division of commitments. A date can identify the source revision around which work is organized. Readiness still describes what the resulting software can support. Combining those meanings into one promise would make a delay in stabilization also remove the next opportunity to evaluate new development.

For downstream users, the immediate value is a recurring artifact to investigate. It does not establish that a production migration should follow the same calendar. Qualification can start against a known artifact while deployment remains contingent on the version's eventual release state.

The alpha proposal began with downstream qualification

In his 8 November explanation, McKenzie identifies a qualification checkpoint as a motivation for quarterly alphas. Core contributors can already build a chosen commit. Users outside the development group face more friction in producing a distribution and deciding which revision deserves attention.

A shared artifact reduces that selection problem. Different evaluators can reproduce behavior against the same identified source state. Their findings become easier to compare than reports against moving trunk revisions chosen independently.

That is a practical distinction between availability of source and accessibility of testing. Public commits make experimentation possible. A named artifact gives users a common candidate around which to organize compatibility work.

The discussion also presents regular artifact creation as a possible incentive to improve CI and release processes. That is an intended pressure on development practice, rather than evidence that the policy itself has already removed flaky tests. A schedule creates recurring obligations that maintainers still have to fulfill.

Formal release procedure does not imply production maturity

Mick's response distinguishes a formally governed source release from its quality stage. He argues that artifacts announced to the user community should go through the normal release vote, even when they remain alpha quality and do not appear on the normal download page.

That distinction resolves a terminology problem in the proposal. An artifact can have an approved origin and a reproducible source identity while still being unsuitable for supported production use. Release governance and software maturity answer different questions.

The final policy retains normal voting and artifact preparation for alphas. A successful vote should therefore be interpreted in the context of the advertised alpha status. It does not silently promote every exposed feature to a stable contract.

I find that separation useful when evaluating distributed software. Knowing exactly which code produced a result is necessary for useful testing. It is insufficient to establish how that code behaves across the full range of failures a production installation may encounter.

Feature maturity affects what can enter a release

A 13 November reply addresses the question of choosing features for the scheduled branch. McKenzie describes immature features remaining unexposed, experimental features being available but disabled by default, and mature features being ordinarily available.

He presents that vocabulary as a way of explaining the intended behavior, while acknowledging that formalizing feature stages is another topic. The distinction is important. A discussion of feature maturity should not be reported as a separate completed policy change.

The practical implication is that merging a feature and endorsing its default use are different decisions. A recurring artifact can contain development work under appropriate controls. That lets users test it without requiring the entire release to make the same maturity claim for every feature.

For application teams, this means an evaluation needs to record enabled options as well as the artifact version. A feature that requires an experimental setting should remain identifiable as such in compatibility findings. A version number alone cannot describe every configuration exercised by the test.

Subprojects need stable integration targets too

Stefan Miklosovic's contribution explains the integration benefit for subprojects. Work merged into Cassandra trunk can be difficult to consume when there is no released artifact to target. Quarterly artifacts provide a recurring opportunity to integrate against an identified version.

The same discussion recognizes the cost of forcing quiet subprojects to release solely because a date arrived. That is a different concern from making core development available for integration. A common rhythm can be useful without requiring every project to manufacture a release each quarter.

The final allowance to skip a quarter preserves that distinction. Integrators gain more predictable inputs, while subprojects retain discretion about whether they have changes worth releasing. The maintenance burden remains related to actual work.

These discussions explain the policy's significance beyond its calendar. It supplies repeatable qualification points, a formally governed alpha process and independent stabilization decisions. Users can evaluate an identified development artifact while continuing to base production adoption on the maturity and support status of the resulting release.