I failed to address: > - freeing up folk to start QA (that makes sense to start) immediately I think there's a pre-freeze set of QA that makes sense to do and a post-freeze. What we decide on mergeability of large bodies of work around that branch date will inform what qualifies as a "freeze" in this regard.
On Mon, Apr 17, 2023, at 3:06 PM, Josh McKenzie wrote: > 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. >
