Currently, we anticipate CEP-21 being in a mergeable state around late July/August. We're intending to push a feature branch with an implementation covering much of the core functionality to the ASF repo this week. Doing so will obviously help us get a better idea of the remaining work as we incorporate feedback from the community and to document that outstanding effort more clearly.
> On 6 Mar 2023, at 09:24, Benjamin Lerer <b.le...@gmail.com> wrote: > > Sorry, I realized that when I started the discussion I probably did not frame > it enough as I see that it is now going into different directions. > The concerns I am seeing are: > 1) A too small amount of time between releases is inefficient from a > development perspective and from a user perspective. From a development point > of view because we are missing time to deliver some features. From a user > perspective because they cannot follow with the upgrade. > 2) Some features are so anticipated (Accord being the one mentioned) that > people would prefer to delay the release to make sure that it is available as > soon as possible. > 3) We do not know how long we need to go from the freeze to GA. We hope for 2 > months but our last experience was 6 months. So delaying the release could > mean not releasing this year. > 4) For people doing marketing it is really hard to promote a product when you > do not know when the release will come and what features might be there. > > All those concerns are probably even made worse by the fact that we do not > have a clear visibility on where we are. > > Should we clarify that part first by getting an idea of the status of the > different CEPs and other big pieces of work? From there we could agree on > some timeline for the freeze. We could then discuss how to make predictable > the time from freeze to GA. > > > > Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jmcken...@apache.org > <mailto:jmcken...@apache.org>> a écrit : >> (for convenience sake, I'm referring to both Major and Minor semver releases >> as "major" in this email) >> >>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I would >>> advocate to delay until this has sufficient quality to be in production. >> This approach can be pretty unpredictable in this domain; often unforeseen >> things come up in implementation that can give you a long tail on something >> being production ready. For the record - I don't intend to single Accord out >> at all on this front, quite the opposite given how much rigor's gone into >> the design and implementation. I'm just thinking from my personal >> experience: everything I've worked on, overseen, or followed closely on this >> codebase always has a few tricks up its sleeve along the way to having >> edge-cases stabilized. >> >> Much like on some other recent topics, I think there's a nuanced middle >> ground where we take things on a case-by-case basis. Some factors that have >> come up in this thread that resonated with me: >> >> For a given potential release date 'X': >> 1. How long has it been since the last release? >> 2. How long do we expect qualification to take from a "freeze" (i.e. no new >> improvement or features, branch) point? >> 3. What body of merged production ready work is available? >> 4. What body of new work do we have high confidence will be ready within Y >> time? >> >> I think it's worth defining a loose "minimum bound and upper bound" on >> release cycles we want to try and stick with barring extenuating >> circumstances. For instance: try not to release sooner than maybe 10 months >> out from a prior major, and try not to release later than 18 months out from >> a prior major. Make exceptions if truly exceptional things land, are about >> to land, or bugs are discovered around those boundaries. >> >> Applying the above framework to what we have in flight, our last release >> date, expectations on CI, etc - targeting an early fall freeze (pending CEP >> status) and mid to late fall or December release "feels right" to me. >> >> With the exception, of course, that if something merges earlier, is stable, >> and we feel is valuable enough to cut a major based on that, we do it. >> >> ~Josh >> >> On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote: >>> Hi, >>> >>> We shouldn't release just for releases sake. Are there enough new features >>> and are they working well enough (quality!). >>> >>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I would >>> advocate to delay until this has sufficient quality to be in production. >>> >>> Just because something is released doesn't mean anyone is gonna use it. To >>> add some operator perspective: Every time there is a new release we need to >>> decide >>> 1) are we supporting it >>> 2) which other release can we deprecate >>> >>> and potentially migrate people - which is also a tough sell if there are no >>> significant features and/or breaking changes. So from my perspective less >>> frequent releases are better - after all we haven't gotten around to >>> support 4.1 🙂 >>> >>> The 5.0 release is also coupled with deprecating 3.11 which is what a >>> significant amount of people are using - given 4.1 took longer I am not >>> sure how many people are assuming that 5 will be delayed and haven't made >>> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit >>> more deliberate with releasing 5.0 and having a longer beta phase are all >>> things we should consider. >>> >>> My 2cts, >>> German >>> >>> From: Benedict <bened...@apache.org <mailto:bened...@apache.org>> >>> Sent: Wednesday, March 1, 2023 5:59 AM >>> To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org> >>> <dev@cassandra.apache.org <mailto:dev@cassandra.apache.org>> >>> Subject: [EXTERNAL] Re: [DISCUSS] Next release date >>> >>> >>> It doesn’t look like we agreed to a policy of annual branch dates, only >>> annual releases and that we would schedule this for 4.1 based on 4.0’s >>> branch date. Given this was the reasoning proposed I can see why folk would >>> expect this would happen for the next release. I don’t think there was a >>> strong enough commitment here to be bound by, it if we think different >>> maths would work better. >>> >>> I recall the goal for an annual cadence was to ensure we don’t have lengthy >>> periods between releases like 3.x to 4.0, and to try to reduce the pressure >>> certain contributors might feel to hit a specific release with a given >>> feature. >>> >>> I think it’s better to revisit these underlying reasons and check how they >>> apply than to pick a mechanism and stick to it too closely. >>> >>> The last release was quite recent, so we aren’t at risk of slow releases >>> here. Similarly, there are some features that the *project* would probably >>> benefit from landing prior to release, if this doesn’t push release back >>> too far. >>> >>> >>> >>> >>> >>>> On 1 Mar 2023, at 13:38, Mick Semb Wever <m...@apache.org >>>> <mailto:m...@apache.org>> wrote: >>>> >>>> My thoughts don't touch on CEPs inflight. >>>> >>>> >>>> >>>> For the sake of broadening the discussion, additional questions I think >>>> worthwhile to raise are… >>>> >>>> 1. What third parties, or other initiatives, are invested and/or working >>>> against the May deadline? and what are their views on changing it? >>>> 1a. If we push branching back to September, how confident are we that >>>> we'll get to GA before the December Summit? >>>> 2. What CEPs look like not landing by May that we consider a must-have >>>> this year? >>>> 2a. Is it just tail-end commits in those CEPs that won't make it? Can >>>> these land (with or without a waiver) during the alpha phase? >>>> 2b. If the final components to specified CEPs are not >>>> approved/appropriate to land during alpha, would it be better if the >>>> project commits to a one-off half-year release later in the year? >>
