Cassandra 4.0 gets a branching target tied to testing

The difficult question in Cassandra's 4.0 planning discussion is who will test the database once new work stops. An earlier feature freeze gives the project a smaller set of changes to stabilize. A later one may attract the people and workloads needed to find distributed-system defects. The development list has spent considerable effort on that disagreement, and it explains the significance of the branching target now taking shape.

Nate McCall's May message closing the roadmap discussion says the community is aiming to branch 4.0 and freeze during the first week of September. He says an official vote does not appear necessary. This is a development target. It does not announce a production release in September or assert that the feature set is already complete.

I am attracted to Cassandra because active-active operation at scale is a difficult problem that it addresses directly. That makes the testing argument particularly relevant to my view of the project. The reason to choose this database is also a reason to care about behavior that a small, isolated functional test cannot establish.

Feature scope and testing resources are connected

The April development archive records the substance behind the agreement. Ben Bromhead proposes separating work that contributors can resource from desirable work without committed people. He also suggests cleaning up ticket labels so the prospective release has a bounded set of changes. That is a practical response to an expanding changelog. A ticket's presence in a release list does not supply an implementer or a reviewer.

Bromhead describes Instaclustr's commitment to use release candidates on internal staging and production workloads before general availability. His argument for a branch is that it gives such work a defined target. Testing against a codebase that keeps accepting large changes creates repeated work. A branch restricted to bug fixes gives participants a more stable object to evaluate.

The thread also contains a different concern. Jeff Jirsa argues that a release needs enough relevant changes to attract people capable of finding difficult bugs. A small set of changes might reduce the amount of code to validate while also reducing the number of interested testers. Those effects cannot be separated by looking only at the length of the changelog.

This is a limitation of release planning based entirely on ticket counts. Two changes can require very different validation effort. More importantly, a tester needs a reason to allocate time and infrastructure to the candidate. The discussion makes those resource commitments part of the scheduling decision instead of treating testing as work that happens automatically after development.

The argument for an earlier cutoff remains substantial

Jonathan Ellis objects to the assumption that waiting until September will produce more testing. His April response argues that the delay can simply postpone delivery, with additional destabilizing patches arriving meanwhile. He also describes a tendency for users to wait for an alpha, beta or final release before testing. These are arguments against treating promises of future participation as completed validation.

That objection survives the eventual agreement. Selecting September does not prove that September will produce enough useful evidence. It gives participants a date around which to arrange their commitments. The distinction matters because the target is valuable only insofar as it changes what contributors actually do.

The archive shows concrete reasons for preferring the later date. Joseph Lynch says the Netflix team cannot perform full certification earlier and may be able to schedule end-to-end and performance testing around the end of the third quarter or beginning of the fourth. Other participants offer time for operational validation. Those statements explain why the debate moves beyond a simple preference for faster or slower releases.

I find the discussion more useful when it names that capacity. A statement about available validation work can inform a schedule. An abstract claim that a release needs more time cannot explain what the extra time buys or whose participation it enables.

Branching does not finish stabilization

A branch and a freeze define the changes allowed into a release effort. They do not establish that the existing changes work together. Bromhead's proposal describes moving into an alpha, beta and release-candidate cycle with bug fixes on the release branch. Jirsa also argues for an extended testing period even if the desired changes were to arrive immediately.

The practical consequence is that a September branching target cannot be read as a September upgrade date. Feature completion and readiness for production are separate judgments. An operator evaluating the plan should understand which one the community has scheduled. Here the May message identifies branching and freezing.

The proposed feature discussions also need careful interpretation. Contributors mention virtual tables, internode networking work and other possible changes. A request for inclusion is evidence of interest, not evidence that the change has landed. The agreement supplies a time boundary without turning the earlier wish lists into release guarantees.

This approach leaves room for unfinished work to miss the cutoff. That can be uncomfortable when a change would benefit from a major version boundary. It also gives contributors an alternative to letting every desirable feature extend the release effort. The April proposals explicitly contemplate moving incomplete work into a later release.

For people following Cassandra's development, the immediate result is a target around which testing commitments can become specific. The May closure establishes early September as the intended point for branching and freezing. The remaining work includes the validation discussed in April, with different participants supplying application workloads, certification effort or operational scenarios according to what they can actually run.