Cassandra connects annual releases to three years of support

Cassandra's release-cadence discussion starts with a maintenance constraint. More frequent releases create more branches to support unless the project shortens support for each one. Existing users then face more frequent upgrades, while contributors divide their work across additional versions. Choosing a release interval therefore also chooses part of the operating cost for the community that maintains the database.

The May 31 community update reports agreement on one release each year, periodic trunk snapshots and support for three release lines. Incoming releases are to receive three years of support. The announcement places that policy beside the continuing work toward 4.0 general availability. It does not report that 4.0 has already become generally available.

I welcome a release policy that makes maintenance commitments legible. Cassandra is attractive when its distributed behavior solves a real requirement, but adopting it also means choosing an upgrade obligation. A predictable support period gives that obligation a more concrete basis. The earlier mailing-list discussion explains why the project connects the calendar to the number of branches it can maintain.

Branch count constrains the calendar

Benjamin Lerer opened the release discussion on January 26. He asked about release cadence and how the project would maintain release quality. His example exposed the support arithmetic. Cassandra 2.2 had received support for more than five years, and sustaining comparable lifetimes would become difficult if a new version appeared every six months.

That is a capacity problem even before considering which features enter a release. Each retained branch represents another place where relevant fixes may need attention. A release interval cannot be evaluated independently of the number of versions still receiving support. Lerer's opening message therefore treats the support lifetime as part of the cadence decision.

His message also distinguishes a minor version containing compatible improvements from a major version containing compatibility breaks. The examples use 4.1 and 5.0, respectively. These were definitions offered to clarify the discussion, not announcements of particular releases. The distinction becomes relevant because an annual calendar does not by itself settle what version number a release should receive.

The opening message proposes revisiting the chosen cadence if experience shows that it needs adjustment. That qualification is reasonable for a community-maintained database. A calendar can state an intention, but it cannot guarantee that the work required to maintain quality will fit every cycle. The discussion needs a way to keep release scope compatible with that constraint.

The proposal depends on the condition of trunk

In his January 26 reply, Benedict Elliott Smith favors an annual major release with minor releases as necessary. His reasoning includes the burden of faster cadences on developers and users. Slower cadences create a different problem because too many desired changes accumulate around a distant release opportunity.

He pairs the annual schedule with stricter merge criteria and a trunk that remains close to releasable. Under that proposal, the project would release the features already merged around the expected time. Commits that break the branch might need reverting. This is an implementation condition for the proposed cadence, rather than an assurance that assigning dates alone produces reliable releases.

Periodic snapshots have a related purpose in his argument. Contributors who consume trunk ahead of a release can exercise changes earlier. That can reduce pressure to include a feature just before the annual window closes. The argument depends on snapshots becoming suitable for that use, which he states as an objective. It does not establish that every snapshot already has the guarantees of a supported release.

This distinction matters to users reading the May announcement. A supported annual release and a periodic trunk snapshot occupy different positions in the policy. Snapshot availability creates an opportunity for earlier feedback. It does not give each snapshot its own three-year maintenance commitment. Confusing those roles would recreate the support burden the discussion is trying to contain.

Agreement leaves some transition questions open

Lerer's March 29 summary records the annual cadence, periodic snapshots and three supported releases. It says each incoming release should receive three years of support. That summary precedes the May roundup, so the roundup reports an agreement reached through an earlier discussion. The distinction keeps the announcement's date separate from the history of the decision.

The March summary also names unresolved questions. Participants had not reached a clear agreement on version naming, including semantic versioning and snapshot names. The remaining support period for 3.11 also needed clarification because that line was already several years old. Applying a new support policy to incoming releases is easier than deciding how to treat branches created under earlier expectations.

Joseph Lynch's reply later that day explains why the transition deserves separate attention. He reports installations only then finishing upgrades to 3.0 because correctness and performance problems had taken time to resolve. His account concerns those deployments and does not measure adoption across the entire community. It nevertheless explains why a support deadline calculated solely from the original release date can concern users with lengthy upgrade schedules.

Lynch proposes a staged support arrangement that distinguishes full support from fixes for high-severity correctness and performance issues. His suggested calendar assumes an April 4.0 release. That assumption is part of a proposal and should not be presented as an actual release date. The substantive concern is that time elapsed since a branch first appeared may differ from the time users have considered it practical to adopt.

I regard that transition problem as the most useful qualification to the annual policy. A new cadence can make future obligations clearer while leaving older branches in need of an explicit decision. The May announcement establishes the intended annual rhythm and support duration for incoming releases. The earlier discussion explains why users of existing lines still need branch-specific support information, especially where the proposed transition distinguishes full maintenance from high-severity fixes.