I'd say the biggest reasons to me are (1) and (2). For example, we recently worked on CASSANDRA-20749 <https://issues.apache.org/jira/browse/CASSANDRA-20749> due to an internal need for this functionality, and fortunately we’ve been able to bring it upstream. But, since we run 4.1 and 5.0, we brought this patch back to these versions so that we are able to use this feature today.
To your point in (3), I'd say it's easier to qualify a release built off of a stable GA than trunk, especially once the GA release has gotten to where 4.1 is. I’d love to get to the point where we’re qualifying and running trunk builds in production, but even when we get there I still see a world where we still need to run the latest GA alongside trunk which would still motivate us to bring patches back to the latest GA where we need them. On Mon, Oct 20, 2025 at 3:24 PM Josh McKenzie <[email protected]> wrote: > We had a long conversation about the potential of piloting a supported > backport release branch here: > https://lists.apache.org/thread/xbxt21rttsqvhmh8ds9vs2cr7fx27w3k > > When I tried to summarize the thread and identify next steps, one > observation stood out: I think we did a good job establishing the shape > of the challenge we'd like to address (people want to work on OSS, not > maintain private forks), but I don't think we got to the root of why this > challenge exists. If we take action now we run the risk of having the wrong > solution to the right problem. > > So: why are people running forks? Some reasons I've seen brought up: > > 1. You need bespoke code to integrate with internal infrastructure > 2. You've written a new feature targeting your internal version, > upstreamed the code, and have to wait for the feature to be in a GA release > 3. Someone else has contributed a feature to trunk that's attractive > and it's less work or more palatable to back-port it to your private fork > and maintain the diff than to qualify a custom release off trunk > 4. You have stability concerns with GA releases or running a release > based off trunk > > The backport branch we discussed in the previous thread would primarily > address #4 (stability concerns) and secondarily #2 and #3 (feature > availability). All four motivations could be addressed in other > ways—ideally by reducing the pressure to fork in the first place, rather > than accommodating forks as inevitable. > > If you're running a fork and open to sharing your experience, do these > reasons match yours, or is something else at play? The more detail we can > gather, the better we can target improvements where they'll actually help. > > I know these conversations take time and can be hard; I appreciate > everyone taking the time and energy to help us collectively improve. > > ~Josh > >
