Not so fast... There's certainly value in spending that time stabilizing the already done features. It's valuable triaging information to say this used to work before CEP-21 and only broke after it.
That said, having a very long freeze of trunk, or alternatively having a very long lived 5.0 branch that is waiting for Accord and diverging with a trunk that is not frozen... are both undesirable options. (A month or two could IMO be discussed though.) So I agree with the concern from that point of view, I just don't agree that having one batch of big features in stabilization period is zero value. henrik On Fri, Mar 24, 2023 at 5:23 PM Jeremiah D Jordan <jeremiah.jor...@gmail.com> wrote: > Given the fundamental change to how cluster operations work coming from > CEP-21, I’m not sure what freezing early for “extra QA time” really buys > us? I wouldn’t trust any multi-node QA done pre commit. > What “stabilizing” do we expect to be doing during this time? How much of > it do we just have to do again after those things merge? I for one do not > like to have release branches cut months before their expected release. It > just adds extra merge forward and “where should this go” > questions/overhead. It could make sense to me to branch branch when CEP-21 > merges and only let in CEP-15 after that. CEP-15 is mostly “net new stuff” > and not “changes to existing stuff” from my understanding? So no QA effort > wasted if it is done before it merges. > > -Jeremiah > > On Mar 24, 2023, at 9:38 AM, Josh McKenzie <jmcken...@apache.org> wrote: > > 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? > >>> > >>> > > > -- Henrik Ingo c. +358 40 569 7354 w. www.datastax.com <https://www.facebook.com/datastax> <https://twitter.com/datastax> <https://www.linkedin.com/company/datastax/> <https://github.com/datastax/>
