> What about the following idea: allow community-approved feature backports to *latest GA* (with a brief window allowing backports to 2 GA branches) and tier releases as follows
Yeah, I would rather have this than separate, "second-class citizen" branches. It relies on us exercising good judgement about what gets in, but it doesn't discourage upgrades or (de-facto) introduce a new branch in the normal development workflow. On Wed, Oct 8, 2025 at 1:07 PM Jaydeep Chovatia <[email protected]> wrote: > >What about the following idea: allow community-approved feature backports > to *latest GA* (with a brief window allowing backports to 2 GA branches) > and tier releases as follows: > > Makes sense to me. We can define a policy, such as initiating a thread, > similar to "VOTE," and requiring three binding votes and no vetoes, etc. > Initially, we can be more conservative by increasing the binding vote count > from 3 to 5 or even higher; that way, everyone will have a chance to > provide an opinion, yet it remains structured enough so that only > community-intended features get backported. > > Jaydeep > > On Wed, Oct 8, 2025 at 7:59 AM Štefan Miklošovič <[email protected]> > wrote: > >> >> >> On Wed, Oct 8, 2025 at 2:53 PM Josh McKenzie <[email protected]> >> wrote: >> >>> Thanks for the discussion - it looks like we agree on the problem and >>> the trade‑offs involved. >>> >>> Maintaining an extra branch would add toil: we’d have to merge bug >>> fixes, run CI (including upgrade tests), and extend the already lengthy >>> upstream path. A simpler alternative is to relax our backport restrictions >>> on GA branches. >>> >> >> Yes, this would mean CEP-37 would go to 5.0.x, for example. I do not have >> a problem with that in general, I am just not sure if we can "abuse" a >> patch release for this kind of addition. It would really have to be >> "non-disruptive as much as possible". This would be in line with what Jeff >> / Jeremiah / myself were suggesting as well. We would not need to introduce >> a new branch, upgrade paths would be tested as they are now, bug fixes >> would be added too ... >> >> Looking forward to the opinions of other people. >> >> >>> >>> What about the following idea: allow community-approved feature >>> backports to *latest GA* (with a brief window allowing backports to 2 >>> GA branches) and tier releases as follows: >>> >>> *When a new release is cut:* >>> >>> - New release / Latest GA (6.0): stabilizing (backports accepted) >>> - Middle GA (5.0): backports accepted >>> - Oldest GA (4.1): stable >>> >>> *When the new release stabilizes:* >>> >>> - Latest GA (6.0): backports accepted >>> - Middle GA (5.0): stable >>> - Oldest GA (4.1): stable >>> >>> This approach gives users a clear choice - stable, backport‑enabled, or >>> a temporary stabilizing branch - without adding CI overhead. >>> >>> On Wed, Oct 8, 2025, at 5:42 AM, Štefan Miklošovič wrote: >>> >>> Hi Dinesh, >>> >>> thanks for reassuring that this branch would be really just for crucial >>> functionality where benefits justify the backport. I would be more willing >>> to entertain that idea but I still think that once people see 5.1 is up >>> they will want to support their case and there will be a lot of pressure to >>> backport this and that. Not all CEPs / features will make it. We need to be >>> very selective. There will be a lot of "massaging" around what can go in >>> and what not and the expectations would need to be set from the very >>> beginning and followed. >>> >>> However, I am not still quite sure how that would work in general, >>> reading Josh email here: >>> >>> "The branch would selectively accept non‑disruptive improvements that >>> meet criteria we define together." >>> >>> Once people are on 5.1, they will want to have all the bug fixes in >>> there as well. So instead of merging from 4.0 to 4.1, 5.0 and trunk, we >>> will be doing 4.0. 4.1, 5.0, 5.1 and trunk? >>> >>> If the answer is yes, then we will have just another branch we need to >>> fully maintain. >>> >>> If the answer is no, as in we will skip 5.1 on merges from 4.0 to trunk, >>> then I think this will be met with disappointment and questions as to why >>> we are not patching 5.1 as well. >>> >>> Basically we go all in and maintain 5.1 with all the patches from lower >>> branches or we just maintain and backport important features but then ... >>> who is going to use it like that - without receiving bug fixes. >>> >>> >>> >>> On Wed, Oct 8, 2025 at 9:46 AM Dinesh Joshi <[email protected]> wrote: >>> >>> Stefan, Sam – your concerns are absolutely valid and have come up in >>> various discussions. >>> >>> Here's the reality though – many large operators of Cassandra are >>> maintaining backports of various features. The proposal here is to try and >>> allow these contributors to maintain them in the community instead of >>> internally. This is a limited time pilot to see if this model could work. >>> >>> When we "open the flood gates" then the existence of a backporting >>> branch will be the justification of anything they want to see there because >>> they do not want to upgrade. >>> >>> >>> Stefan — nobody is talking about “opening the floodgates” here. The >>> expectation is that small, self contained features could be back ported on >>> a case by case basis. Let’s engage on the criteria that makes sense. >>> >>> On the subject of avoiding backports and using it as a tool to “force” >>> people to upgrade, I’d like to point out that if upgrades were easier we >>> would not be having this discussion. The simple fact is that upgrades are >>> not easy and they are riskier than maintaining backports hence we see this >>> pattern. >>> >>> If the community gets together and makes upgrades easier we will likely >>> not have a need for backports. >>> >>> My suggestion is to engage with “how” this pilot would look like to >>> shape it. It is a limited time experiment that might benefit the community. >>> A number of contributors have shown interest so ideally we should be open >>> to trying it out. >>> >>> >>> >>> On Wed, Oct 8, 2025 at 12:12 AM Sam Tunnicliffe <[email protected]> wrote: >>> >>> I second Štefan's concerns here. The proposal reduces the incentive to >>> upgrade or even test trunk, meaning that the things users want to avoid >>> (features etc, but also just refactorings/re-implementations) because they >>> are as-yet "untrusted" or "unqualified" remain that way for longer. This >>> feels pretty antithetical to the direction we've been aiming to travel in, >>> toward more regular release cycles. >>> >>> >>> > On 8 Oct 2025, at 06:41, Štefan Miklošovič <[email protected]> >>> wrote: >>> > >>> > This is indeed an interesting idea but please let me share my point of >>> view and somehow different opinion on that. >>> > >>> > I share the questions with Jeff and Jeremiah a lot. I see it similarly >>> and they got the point. >>> > >>> > Before 5.0 was out, we had quite a situation where we officially had >>> to take care of 3.0, 3.11, 4.0 and 4.1 at the same time. If a bug was >>> found, we had to patch 5 branches at once (trunk as well). That meant 5 CI >>> jobs. The patching was an endeavour spanning multiple days, realistically. >>> Once 5.0 got out, we officially discontinued 3.0 and 3.11. But what I have >>> been experiencing was that this information about not supporting 3.0 / 3.11 >>> was spreading very slowly among people / customers and I / we had to >>> repeatedly explain to everybody that yes, 3.0 and 3.11 and done. What are >>> they? Done? Yes, done. 3.0 and 3.11 are finished. Finished you say? That >>> means no patches? Yes, no patches. Aha right ... For real? ... you got it. >>> People had to internalize that it is just not going to happen. >>> > >>> > When we "open the flood gates" then the existence of a backporting >>> branch will be the justification of anything they want to see there because >>> they do not want to upgrade. Instead of us working towards a more smooth >>> upgrade we are burying ourselves with older stuff. That slows adoption of >>> new majors a lot. People will not be forced to, there will be way less >>> incentive to do that when all the important goodies are backported anyway. >>> > >>> > I see that "the backports would be non-disruptive but potentially >>> higher risk". I do not completely understand what this means in practice. >>> Let's say CEP-37. Is that disruptive or not? What's the definition of that? >>> To me, correct me if I am wrong, is that something is disruptive if I just >>> can not turn it off even if I do not want to use it. Does one _have to_ use >>> CEP-37 when it is backported? No. They can just turn it off. So what is >>> exactly the risk of introducing it to e.g. 5.0.x ? >>> > >>> > Also, how are upgrades done? People are going to upgrade from 5.0.x to >>> 5.1 and then it will be possible to upgrade to 6.0 from 5.1? This would >>> need us to make the pipelines, incorporate this new path into upgrade tests >>> and so on ... a lot of work. >>> > >>> > I think that the current policy - "only bug fixes to older branches" >>> might be relaxed a bit instead and leverage already existing upgrade paths >>> and infrastructure to test it all instead of creating brand new branches we >>> need to take care of. >>> > >>> > Regards >>> > >>> > On Mon, Oct 6, 2025 at 6:04 PM 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 >>> >>> >>>
