We expect users to treat patch and minor releases as low risk. Changing something deep in the storage engine to be 1% faster is not worth the risk, because most users will skip the type of qualification that finds those one in a billion regressions.
Patch releases are for bug fixes not perf improvements. > On Jan 21, 2025, at 9:10 PM, Jordan West <jw...@apache.org> wrote: > > > Hi folks, > > A topic that’s come up recently is what branches are valid targets for > performance improvements. Should they only go into trunk? This has come up in > the context of BTI improvements, Dmitry’s work on reducing object overhead, > and my work on CASSANDRA-15452. > > We currently have guidelines published: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Wheretoapplypatches. > But there’s no explicit discussion of how to handle performance > improvements. We tend to discuss whether they’re “bugfixes”. > > I’d like to discuss whether performance improvements should target more than > just trunk. I believe they should target every active branch because > performance is a major selling point of Cassandra. It’s not practical to ask > users to upgrade major versions for simple performance wins. A major version > can be deployed for years, especially when the next one has major changes. > But we shouldn’t target non-supported major versions, either. Also, there > will be exceptions: patches that are too large, invasive, risky, or > complicated to backport. For these, we rely on the contributor and reviewer’s > judgment and the mailing list. So, I’m proposing an allowance to backport to > active branches, not a requirement to merge them. > > I’m curious to hear your thoughts. > Jordan
