> I would like to propose a partial freeze of 5.0 in June My .02: +1 to: * partial freeze on an agreed upon date w/agreed upon other things that can optionally go in after * setting a hard limit on when we ship from that frozen branch regardless of whether the features land or not
-1 to: * ever feature freezing trunk again. :) I worry about the labor involved with having very large work like this target a frozen branch and then also needing to pull it up to trunk. That doesn't sound fun. If we resurrected the discussion about cutting alpha snapshots from trunk, would that change people's perspectives on the weight of this current decision? We'd probably also have to re-open pandora's box talking about the solidity of our API's on trunk as well if we positioned those alphas as being stable enough to start prototyping and/or building future applications against. On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote: > I am +1 on a 5.0 branch freeze. > > Kind Regards, > Brandon > > On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer <ble...@apache.org> wrote: > >> > >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? > > > > > > I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and > > allowing only CEP-15 and 21 + bug fixes there. > > Le ven. 24 mars 2023 à 13:55, Paulo Motta <pauloricard...@gmail.com> a > > écrit : > >> > >> > I would like to propose a partial freeze of 5.0 in June. > >> > >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I agree > >> with a branch freeze, but not with trunk freeze. > >> > >> I might work on small features after June and would be happy to delay > >> releasing these on 5.0+, but delaying merge to trunk until 5.0 is released > >> could be disruptive to contributors workflows and I would prefer to avoid > >> that if possible. > >> > >> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever <m...@apache.org> wrote: > >>> > >>> > >>>> I would like to propose a partial freeze of 5.0 in June. > >>>> > >>>> … > >>>> > >>>> This partial freeze will be valid for every new feature except CEP-21 > >>>> and CEP-15. > >>> > >>> > >>> > >>> +1 > >>> > >>> Thanks for summarising the thread this way Benjamin. This addresses my > >>> two main concerns: letting the branch/release date slip too much into the > >>> unknown, squeezing GA QA efforts, while putting in place exceptional > >>> waivers for CEP-21 and CEP-15. > >>> > >>> I hope that in the future we will be more willing to commit to the > >>> release train model: less concerned about "what the next release > >>> contains"; more comfortable letting big features land where they land. > >>> But this is opinion and discussion for another day… possibly looping back > >>> to the discussion on preview releases… > >>> > >>> > >>> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21) landing > >>> in trunk? > >>> > >>> >
