CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy) should both be ready for review by mid-April.
Both are around 10k LOC, fairly isolated, and in need of a committer to review. Regards, Branimir On Mon, Mar 6, 2023 at 11:25 AM 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> 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> >> *Sent:* Wednesday, March 1, 2023 5:59 AM >> *To:* dev@cassandra.apache.org <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> 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? >> >> >>
