Cassandra ends tick-tock under the cost of release validation

Cassandra's discussion about ending tick-tock begins with an estimate of human work. In his 10 January proposal, Jonathan Ellis says that verifying a release takes about a person-week. The work includes examining failing tests and rerunning them to distinguish a database defect from an unreliable test. A monthly release schedule has to fund that work every month, even when the change list looks small.

That estimate explains why a release-policy discussion belongs alongside storage and query design. The software that users can safely install depends on people resolving ambiguous evidence. Running the tests produces results, but someone still has to determine what those results mean. Ellis argues that Cassandra cannot sustain the proposed monthly cadence with its available validation effort.

By February, the project is moving away from tick-tock. The contemporary mailing-list discussion supplies the reasoning behind that direction without requiring a prediction about the next major release. Its participants broadly support ending the existing scheme, while disagreeing about how far to lengthen the feature-release interval. That disagreement matters because both frequent releases and infrequent releases impose costs.

I am interested in Cassandra because its distributed deployment model addresses demanding systems requirements. Release policy is part of the cost of choosing that model. A useful maintenance branch lets an operator obtain corrections without making every upgrade a decision about another set of database capabilities.

Validation has a recurring cost

Ellis's proposal describes much of the validation cost as fixed. In his account, unreliable tests require investigation even when the development interval is short. A longer interval spreads that repeated work across more development. His proposed replacement is approximately annual feature releases, with bug-fix releases on stable branches as needed, probably every two months.

This is an argument about the project's actual resources. It does not claim that monthly releases are inherently unsuitable for databases. Ellis explicitly leaves room for a faster cadence if the pool of quality-assurance effort grows or unreliable tests become sufficiently rare. The proposed schedule follows the available means of establishing release quality.

The difference between a failing test and a defective product is central here. A test failure can indicate a database bug, but it can also indicate a problem in the test or its execution environment. Deciding between those explanations requires evidence. Repeated execution can help, yet rerunning alone does not explain a failure or establish that the tested behavior is correct.

The parallel discussion about blocking releases on distributed tests makes that concern concrete. Ariel Weisberg argues that at least some failures are real and questions who will investigate the reported failures. He also argues that tests which fail spuriously cannot perform their intended checking role effectively. That position treats test maintenance as work on the database's development infrastructure.

There are therefore two related tasks. The project must identify defects in the candidate release, and it must maintain tests that produce interpretable results. Delaying the second task increases the effort required for the first. A schedule that assumes every result is immediately decisive overlooks the investigation described in these threads.

Longer development creates another problem

Jonathan Haddad's reply to the proposal argues against returning all the way to an annual cycle. He recalls that the motivation for tick-tock included the difficulty of stabilizing a large collection of interacting features. Shortening the interval was intended to reduce the amount of new behavior entering a release at once.

Haddad proposes feature releases every six months, with monthly bug fixes for a year. His reasoning includes keeping the set of maintained feature releases small while allowing time for stabilization. This separates the interval between new capabilities from the interval between corrections. Those intervals answer different needs and do not have to match.

In another reply, Blake Eggleston supports a six-month compromise. His message also preserves Weisberg's concern that a year of development can accumulate unfinished work. If stabilization begins only when a release approaches, earlier features spend a long time waiting for the rest of the branch to become usable.

That is a different cost model from the fixed validation effort. The amount of investigation needed to interpret unreliable tests may recur with each release. The number of interactions among unfinished changes can grow as development continues. A practical cadence has to account for both, and a reduction in release frequency does not automatically reduce every kind of release work.

I find the six-month argument persuasive because it addresses the amount of change awaiting validation as well as the frequency of validation. That is a judgment about the proposals, not a claim that a particular interval guarantees stability. The discussion itself gives reasons to distrust such a guarantee when the test results still need substantial interpretation.

Maintenance branches change the operator's choice

A stable branch needs its own bug-fix releases. The proposals make that requirement explicit, although they differ on the interval and support period. This is the operational benefit of separating feature development from maintenance. An application can remain on a chosen set of capabilities while the database receives corrections to that implementation.

Without that separation, obtaining a fix can require accepting unrelated behavior changes. Maintaining private patches is another possible response, but it transfers integration work to the user. Dikang Gu's contribution to the same discussion, preserved in the 10 January archive, argues for frequent minor releases so users do not have to wait six months for fixes or maintain many patches internally.

The number of maintained branches affects developers as well. Haddad's proposal explicitly identifies support for the current and previous releases as an advantage. Each additional supported line expands the set of places where a correction may need assessment. A project can publish many version numbers without having enough people to validate every branch to the same standard.

The parallel test discussion also exposes a limitation of issue-tracker metadata. In his reply about release blockers, Michael Shuler explains that fix-version values generally had been assigned during commits. He had marked a few issues against 3.10 to draw attention to failures that had blocked votes. A query for unresolved issues assigned to the release therefore did not necessarily describe every outstanding test failure.

That distinction changes how maintainers interpret a candidate. An empty list of assigned blockers does not establish that all relevant tests pass. Shuler points to the broader test-failure list and asks whether a current authentication-test failure should block the release. Rerunning the job might produce a different result, but it would not answer the underlying question about the failure.

A release process needs agreement about which evidence is sufficient, alongside agreement about which issues belong to a version. The messages show contributors trying to establish that relationship while also completing the delayed release. A longer calendar interval leaves this requirement intact. Without an explicit treatment of unexplained failures, a project can reach its next scheduled date with the same uncertainty about the candidate.

A schedule cannot replace maintained tests

Ending tick-tock does not settle when every future release will happen. The January messages contain proposals and support for different intervals, alongside agreement that the current approach should end. It is more accurate to preserve those distinctions than to turn the discussion into a promise of a fixed future calendar.

The proposals do establish that validation capacity limits release frequency. Adding another scheduled release consumes investigation effort even when the candidate contains few changes. Improving the reliability of tests can change that calculation because maintainers spend less time determining whether a failure is meaningful. Increasing the number of people able to perform that investigation can change it as well.

An operator cannot infer those improvements from a new schedule alone. The useful change is the explicit recognition that maintenance needs its own supported path and that each release needs interpretable evidence. This makes release work part of the engineering model of the project, with identifiable costs and competing demands.

For Cassandra users, the immediate consequence is a clearer distinction between following new feature development and staying on a maintained implementation. The remaining work includes defining support periods and keeping corrections moving through those maintained branches. Those choices determine whether the proposed reduction in branch and validation effort also gives deployments a practical way to receive fixes.