(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?
