Hi cassandra-dev@, 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 earlier.
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 reached. 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 appreciated. 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, Sankalp Kohli
