Thanks everybody for the feedback. It seems to me that considering that Accord (CEP-15) depends on Transactional Cluster Metadata (CEP-21) and that, according to Sam, CEP-21 could land late July/August, Accord will probably not be fully merged before late August/September. That brings us quite late in the year and exposes us to the risk of not releasing this year. Therefore, I wonder if we should not slightly change the way we approach the release this year to minimize the risk of not releasing this year while getting a 5.0 version with all the most anticipated features. I would like to propose a partial freeze of 5.0 in June. At which point we could expect, based on people's feedback, most CEPs and big features, outside of CEP-21 and CEP-15, to have been committed to trunk. This partial freeze will be valid for every new feature except CEP-21 and CEP-15. That approach will allow us to start stabilizing the 5.0 branch before the 2 CEPs are merged and it will also prevent the goal post from moving. Reducing the time needed to release after the merge. What do you think?
Le jeu. 16 mars 2023 à 12:38, Mike Adamson <madam...@datastax.com> a écrit : > Sorry, I realised that I hadn't included any completion date for CEP-7. At > the current time we are looking at completion mid to end of April. > > Mike > > On Mon, 13 Mar 2023 at 11:34, Mike Adamson <madam...@datastax.com> wrote: > >> CEP-7 Storage Attached Index is in review with ~430 files and ~70k LOC. >> The bulk of the project is in 3 main patches. The first patch (in-memory >> index and query path) is merged to the feature branch CASSANDRA-16052 and >> the second patch (on-disk write and literal / string index) is in review. >> >> Mike >> >> On Thu, 9 Mar 2023 at 09:13, Branimir Lambov <blam...@apache.org> wrote: >> >>> 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? >>>>> >>>>> >>>>> >> >> -- >> [image: DataStax Logo Square] <https://www.datastax.com/> *Mike Adamson* >> Engineering >> >> +1 650 389 6000 <16503896000> | datastax.com <https://www.datastax.com/> >> Find DataStax Online: [image: LinkedIn Logo] >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=> >> [image: Facebook Logo] >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=> >> [image: Twitter Logo] <https://twitter.com/DataStax> [image: RSS >> Feed] <https://www.datastax.com/blog/rss.xml> [image: Github Logo] >> <https://github.com/datastax> >> >> > > -- > [image: DataStax Logo Square] <https://www.datastax.com/> *Mike Adamson* > Engineering > > +1 650 389 6000 <16503896000> | datastax.com <https://www.datastax.com/> > Find DataStax Online: [image: LinkedIn Logo] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=> > [image: Facebook Logo] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=> > [image: Twitter Logo] <https://twitter.com/DataStax> [image: RSS > Feed] <https://www.datastax.com/blog/rss.xml> [image: Github Logo] > <https://github.com/datastax> > >
