Re: [EXTERNAL] [DISCUSS] Next release date

[J. D. Jordan]

That was my understanding as well. On Mar 30, 2023, at 11:21 AM, Josh McKenzie <jmcken...@apache.org> wrote:  So to confirm, let's make sure we all agree on the definition of "stabilize". Using the definition as "green run of all tests on circleci, no regressions on ASF CI" that we used to get 4.1 out the door, and combined with the metric of "feature branches don't merge until their CI is green on at least CircleCI and don't regress on ASF CI"... that boils down to: a) do we have test failures on circle on trunk right now, and b) do we have regressions on trunk on ASF CI compared to 4.1 Whether or not new features land near the cutoff date or not shouldn't impact the above right? I'm receptive to another definition of "stabilize", having a time-boxed on calendar window for people to run a beta or RC, or whatever. But my understanding is that the above was our general consensus in the 4.1 window. I definitely could be wrong. :) On Thu, Mar 30, 2023, at 5:22 AM, Benjamin Lerer wrote: but otherwise I don't recall anything that we could take as an indicator that a next release would take a comparable amount of time to 4.1? Do we have any indicator that proves that it will take less time? We never managed to do a release in 2 or 3 months so far. Until we have actually proven that we could do it, I simply prefer assuming that we cannot and plan for the worst. We have a lot of significant features that have or will land soon and our experience suggests that those merges usually bring their set of instabilities. The goal of the proposal was to make sure that we get rid of them before TCM and Accord land to allow us to more easily identify the root causes of problems. Gaining time on the overall stabilization process. I am fine with people not liking the proposal. Nevertheless, simply hoping that it will take us 2 months to stabilize the release seems pretty optimistic to me. Do people have another plan in mind for ensuring a short stabilization period? Le lun. 27 mars 2023 à 09:20, Henrik Ingo <henrik.i...@datastax.com> a écrit : 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