Why not just branch a 4.0-rel and bugfix there and merge up while still accepting new features or improvements on trunk?
I don't think the potential extra engagement in testing will balance out the atrophy and discouraging contributions / community engagement we'd get by deferring all improvements and new features in an open-ended way. On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli <kohlisank...@gmail.com> wrote: > 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
