I was keeping rewriting this email to not come across as arrogant or misunderstood.
I see the value in the creation of 5.1 as Mick explained, but what I was trying to do with having it in 5.0.x is just to have less work. As a contributor who is with the codebase basically on a daily basis, when something like this is presented to me, first of all I am seeing "more work" on top of already enough work. The pool of committers is not endless. Concrete people merge it and take care of that. So if we want to introduce 5.1, sure, but please, the other part of the equation here is that people who want to have 5.1 and contribute their backports into that should step up their game, if they already have not, and truly own it. I do not want 5.1 to be _just another branch I need to take care of_ and I expect that concrete people (and / or companies) will be owning it, otherwise what I perceive is that I will be more busy. That also touches releases (if they want to see 5.1 materialized in an official release or not). Who is going to release it? You, Mick, with Brandon? Because it sure won't be me if we (as my employer) do not have an interest in doing so. So I would also expect that there will be concrete people willing to take care of that as well because last time I checked there are basically three people doing releases so asking to take care of releasing more is just ... nah. So, sure, create 5.1, but there are also caveats attached to that so that making it happen and taking care of that also means that the substantial investment from people wanting to see it in the first place is expected an it would be nice if we all realize what we are buying ourselves into otherwise we would just make already busy people more busier than before. On Thu, Oct 9, 2025 at 12:30 AM Mick <[email protected]> wrote: > > > It is fantastic to read this Josh, to see an initiative to create a space to > bring new collaborators and energy into the project. > > Thank you for bringing it forward, representing those down-stream-fork users. > I'm reading this as true to the open source ethos of "scratch your itch", > and I see the value of letting meritocracy do its thing here. Some (not all) > of the objections and concerns I've read seem to be missing the point of what > people are saying they are already doing– and that if we create space and > process for them they can do that work lighter to the benefit of more… > > FTR, I'm not in favour of softening what goes into 5.0.x (see last paragraph > for more), I do believe (despite a long write-up) it can be trivial to > introduce a cassandra-5.1 branch for the pilot, but it would require some up > front agreements. > > My thoughts to this so far… > > - Distinction from the stable branch (Jeff, Stefan): this seems to be about > back porting features from trunk, something we forbid/frown upon doing as it > jeopardises our stable branch. If folk are going to extra effort to back > port into private forks specific features for the value they provide: despite > the risk (and extra effort in private QA-ing) the private back port against > safety and security; and they want to pilot a way to collaborate together to > reduce that effort in the project then we should be supportive of that. Nor > should we hijack our existing stable branches. So yeah, I do see a clear > distinction here. > > - We would need to be careful about what gets back ported (Isaac, Stefan, > Runtian). IMHO this cannot be about "this feature should…" but rather > sticking to the pilot's specific value-add and litmus test: folk are running > this feature in production in their private fork already. So IMHO this > should also exclude any downstream vendor saying "we have customers asking > for this feature so we want to back port it" as I would suggest that's our > slippery slope (this is different to a vendor saying "we are already running > this downstream"). This debunks the floodgates concern– this is not about > what users or vendors "want". This is about what downstream developers a) > are already running in production, and b) are themselves willing to step > forward into the community and do the work in the pilot. We should also be > explicit about the things we cannot accept back ports of: major > protocol/messaging compatibility changes; as Caleb points out. > > - Lifecycle (Jeremiah, Isaac, Stefan): i would suggest that 5.1 becomes a > sibling release branch to 5.0. So yes, it means post 6.0 GA we have an > additional release branch to maintain (and forward merge commits) in > cassandra-5.1, but that it EOLs the same time as 5.0 does. This is a repeat > of what we did with 3.0 and 3.11. I think the overhead of this is minimal– > it might actually make forward merges easier, breaking up the rebasing to > smaller incremental steps (which ironically is parallel value of reducing and > de-risking downstream fork work). But this is still of course a concern to > consider (Stefan's point about CI runs particularly bears weight, see below), > but still I think the question of how long we have to maintain branches is > the bigger concern. Also note (Jeremy), the next major release after 6.0 is > 7.0. Any 6.1 future branch would be a similar back-port of 7.0 dev features > that users have already started using in a downstream production, given the > pilot proves to be successful (this is to be evaluated). > > - More branches, more CI pain (Stefan): yeah, this struck me as a legit > concern. We do now have pre-ci.cassandra.apache.org > <http://pre-ci.cassandra.apache.org/> and I really hope that alleviates most > of the pain here (not just in its availability, but in its accessibility and > use subsequently improve our CI's pipeline efficiency). Accepting that might > not entirely cover it, my suggestion here would be we evaluate whether CI on > the 5.1 is a pre-commit requirement. If a bugfix patch for 5.0 has a > pre-commit run on 5.0 and trunk: like it would today; I'm ok continuing with > that onwards– if it gets the pilot up and running. Seeing the value of the > pilot, I'm happy to contribute to the work involved in adding the upgrade > paths. > > - 5.1 Releases (Francisco): Is this a requirement of the pilot program ? > Saying up front we won't be cutting releases is a surefire way to enforce the > idea this is reserved for downstream devs that solely are looking to > collaborate together on their back ports. But maybe that's a bit harsh. It > would be fair to state clearly that releases off this branch can be fewer, > given its intent. The other question that comes to mind is what QA label > would 5.1.x releases have ? Labelling them as betas is another, but gentler, > approach to messaging what the pilot is for. (And we want to still be > incentivising users to upgrade early and often to the latest GA major > release, and to be incentivising us to be making the upgrade process easier > for users.) > > - 5.1 needs to be maintained past 6.0 GA's date (Jeremiah, Isaac). > Continuing on from above. Users need a window to upgrade from 5.1 to 6.0, so > there has to be an overlap anyway. But I can imagine, and maybe some > downstream users involved here can answer this, that part of the value of > this pilot is that specific dev features in trunk might be a lot harder to > upgrade to than we realise– that it takes ~years to adjust fleets of > production clusters to certain new features in the next major, while other > features are just about back porting but provide value that's simply > unjustifiable for a business to look past (and is what keeps C* being part of > the tech stack in those companies). A 5.1 branch might also serve purpose in > providing specific features that help make the upgrade to the next major > possible/feasible (like support for a blue-green upgrade solution), but this > is purely speculative. > > - How other projects are doing it and their past discussions on what they > decided (Ekaterina). I agree with this– we should reference what they are > doing and why (but also not presume that's how they would do it again today). > Do we know any folk active in any of those projects ? > > > So FTR, based on the discussion so far, I'm really not keen of softening what > goes into 5.0.x, finding having to work on bugs in our stable branches > sometimes hard work, if not at times quite stressful, I really appreciate all > efforts in maintaining their hardness. I see the risk of production > clusters (and our reputation) if we introduce significant bugs a long way > into a stable branches patch versions. This will definitely make folk shy > from upgrades even more. > > IMO the 5.1 pilot seems such the much safer option, so I'm keen we can > address our concerns with it to give those people their room to collaborate > on it (and ofc appreciate the opposing concerns). And added win from this, I > can also see that it helps downstream forks incrementally rebase towards > trunk more often– a huge win for helping find bugs in trunk earlier and to > adopt trunk faster. I see downstream forks struggle to keep up in an > efficient manner, and that rebases onto year+ long new dev branches can be > time-consumingly painful and hard to keep justifying as a ongoing business > priority. I agree that anything to help alleviate this situation: without > removing the option of, or jeopardising/softening, the users safe stable "GA" > experience; would be most welcome. That these folk are stepping forward to > add their efforts in the community under such a pilot experiment is awesome, > and IMHO a strong sign of a healthy growing community. > > Mick > > > > On 7 Oct 2025, at 03:52, Jeff Jirsa <[email protected]> wrote: > > > > I have to admit I feel slow because I genuinely can’t tell what’s > > functionally different from this vs the existing strategy where we … > > selectively write patches for older versions when they’re low risk / high > > reward for safety and security > > > > Setting aside some unspecified nuances you haven’t haven’t defined, what > > makes this different from the existing practice of apply selective patches > > to old releases so users on old builds have a long term stable release that > > gets correctness and security fixes without the risk of new features ? > > > > > > > >> On Oct 6, 2025, at 9:04 AM, Josh McKenzie <[email protected]> wrote: > >> > >> > >> Many large‑scale Cassandra users have had to maintain private feature > >> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on > >> older branches. That duplication adds risk and pulls time away from > >> upstream contributions which came up as a pain point in discussion at CoC > >> this year. > >> > >> The proposal we came up with: an official, community‑maintained backport > >> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot > >> for a year and then decide if we want to make it official. The branch > >> would selectively accept non‑disruptive improvements that meet criteria we > >> define together. There’s a lot of OSS prior art here (Lucene, httpd, > >> Hadoop, Kafka, Linux kernel, etc). > >> > >> Benefits include reduced duplicated effort, a safer middle ground between > >> trunk and frozen GA releases, faster delivery of vetted features, and > >> community energy going to this branch instead of duplicated on private > >> forks. > >> > >> If you’re interested in helping curate or maintain this branch - or have > >> thoughts on the idea - please reply and voice your thoughts. > >> > >> ~Josh >
