So to bring us back to the goals and alignment here: > With the following intentions: > - moving towards the goal of annual releases, with a cadence 12±3 months > apart, > - the branch to GA period being 2-3 months, > - avoiding any type of freeze on trunk, > - getting a release out by December's Summit, > - freeing up folk to start QA (that makes sense to start) immediately So what I *think* falls out logically:
1. We branch cassandra-5.0 on August 1st 2. We expect an 8-12 week validation cycle which means GA Oct1-Nov1. 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk invalidating stabilization and risk our 2023 GA date 3b. If we don't allow merge of CEP-15 / CEP-21 after branch, we risk needing a fast-follow release and don't have functional precedent for the snapshots we earlier agreed upon doing. Does that distill it and match everyone else's understanding? On Mon, Apr 17, 2023, at 2:20 PM, Mick Semb Wever wrote: > > > On Mon, 17 Apr 2023 at 19:31, Caleb Rackliffe <calebrackli...@gmail.com> > wrote: >> ...or just cutting a 5.0 branch when CEP-21 is ready. >> >> There's nothing stopping us from testing JDK17 and TTL bits in trunk before >> that. >> >> On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe <calebrackli...@gmail.com> >> wrote: >>> > Once all CEPs except CEP-21 and CEP-15 land we branch cassandra-5.0 >>> >>> For the record, I'm not convinced this is necessarily better than just >>> cutting a cassandra-5.0 branch on 1 October. > > > How else would this work without being akin to a feature freeze on trunk. > > We want (need) as much time as possible to test. We have no evidence that it > will be quicker than 4.1, we have to create that evidence. Those folk that > free up and are ready to get ahead and de-risk our testing efforts should be > given a release branch to make their work easier and to give us that evidence > in a more controlled manner so that we can plan better next time. Appreciate > that there's one too many variables here, but I'm sticking up for the testing > efforts here.
