> We do not want to encourage/enable the rush to commit stuff before the 1st > May cut-off. IMHO we should be comfortable leaning towards saving any > significant commits for the next dev cycle. With sufficient testing added for a new feature, feature flags for optionality, and a window of time to fuzz test things, why should we shy away from even large commits the day before we freeze if they have a green CI board?
It's up to each of us not to rush or cut corners to try and slip something in. The snapshot releases and yearly cadence should remove a lot of the sting from missing a release deadline I think. On Tue, Mar 8, 2022, at 10:14 AM, bened...@apache.org wrote: > At the very least we should wait until the current issues with CI have > resolved, so that pending work can merge, before declaring any freeze. > > *From: *Mick Semb Wever <m...@apache.org> > *Date: *Tuesday, 8 March 2022 at 15:13 > *To: *dev@cassandra.apache.org <dev@cassandra.apache.org> > *Subject: *Re: [DISCUSS] Next release cut >> >> Should we plan some soft freeze before that? > > > Good question! :-) > > We do not want to encourage/enable the rush to commit stuff before the 1st > May cut-off. IMHO we should be comfortable leaning towards saving any > significant commits for the next dev cycle. How do we create the correct > incentive? > > If we don't feel that we have achieved stable trunk this dev cycle then a > soft feature freeze during April makes sense to me. IMHO a need to first cut > alpha1 instead of going straight to a beta1 is an indicator we have not > achieved stable trunk; > > I'd rather not see a long testing run on the release branch before rc1. And I > think this is necessary if we want GA by July. > So for me this boils down to… are we (and will we be) comfortable making the > first cut 4.1-beta1 ? >
