In the interest of broadening perspectives, thoughts here from two angles: community engagement and marketing. We will be discussing what’s coming in Cassandra 5.0 at Cassandra Forward in 2 weeks. This is meant to build excitement for the next version so having technology for folks to get their hands on soon after, while the news is fresh, would be advantageous for a few reasons...
1. From a community engagement perspective: We want to both deepen community engagement and build a more direct / engaged feedback loop around the release in the absence of an in person event (til Dec), we hope to arrange things like live (virtual) forums for contributors and users to weigh in on features. A May release would give us a runway to create these forums and time to make sure voices are heard through them in the lead to GA. 2. From a marketing perspective: We want to not just excite our existing community, but also grow as we welcome newcomers to the project. Having a new release out there (even in it’s early version) allows us to continue momentum, show consistent innovation, and work on bringing new users and contributors into the fold in the runway to GA. All that said #1 could also be achieved if the project is landing features that will ultimately benefit the 5.0 release. These forums could be built around new feature updates. > On Mar 1, 2023, at 6:59 AM, Benedict <bened...@apache.org> wrote: > > 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?
