Testing 4.0 Post-Freeze
With the goal of making Cassandra's 4.0 the most stable major release to
date, we would like all committers of the project to consider joining us in
dedicating their time and attention to testing, running, and fixing issues
in 4.0 between the September freeze and the 4.0 beta release. This would
result in a freeze of new feature development on trunk or branches during
this period, instead focusing on writing, improving, and running tests or
fixing and reviewing bugs or performance regressions found in 4.0 or
How would this work?
We propose that between the September freeze date and beta, a new branch
would not be created and trunk would only have bug fixes and performance
improvements committed to it. At the same time we do not want to discourage
community contributions. Not all contributors can be expected to be aware
of such a decision or may be new to the project. In cases where new
features are contributed during this time, the contributor can be informed
of the current status of the release process, be encouraged to contribute
to testing or bug fixing, and have their feature reviewed after the beta is
What happens when beta is reached?
Ideally, contributors who have made significant contributions to the
release will stick around to continue testing between beta and final
release. Any additional folks who continue this focus would also be greatly
What about before the freeze?
Testing new features is of course important. This isn't meant to discourage
development – only to enable us to focus on testing and hardening 4.0 to
deliver Cassandra's most stable major release. We would like to see
adoption of 4.0 happen much more quickly than its predecessor.
Thanks for considering this proposal,