I'm kind of neutral on this, maybe -0. It's a small enough patch, but it's of limited value, given that Cassandra Analytics doesn't work with vnodes. That's the overwhelming majority of deployments. So I'm not really sure what we gain here.
On Wed, Jul 31, 2024 at 1:58 PM Yifan Cai <yc25c...@gmail.com> wrote: > Hi PMC team, > > There are so far two +1 and one -1. Please vote if you want to. It is open > for another 12 hours. > > 4.1 is to be released. I would like to include the patch, if possible, > according to the vote result. > > I recognize that patches to stable releases can be risky. When talking > about the trade off, we need to evaluate the benefit holistically, > considering all the projects under the Cassandra umbrella. > We surely do not want to backport the user-facing Cassandra features and > potentially demotivating upgrade. > IMO, the internal changes should be treated differently, as long as the > public interface does not change. In this particular case, Cassandra > Analytics provides the same bulk write feature regardless of backporting > the patch or not. But having the patch backported improves the code quality > and brings other benefits. Hope it answers Mick's message. > > Maybe it is time we start to think about categorizing the interfaces in > Cassandra into 1) public API, 2) internal API, and 3) evolving API, etc. It > is not a suitable topic for this thread and requires a separate discussion. > > - Yifan > > On Tue, Jul 30, 2024 at 11:47 AM Mick Semb Wever <m...@apache.org> wrote: > >> reply below. >> >> We're moving into a world where we will likely more frequently modify >>> the mainline branch with new functionality to integrate with ecosystem >>> changes (sidecar, analytics, drivers?). It's probably at least worth a >>> conversation as to whether our current policy (improvements and new >>> features main branch only) is optimal across everything equally or if there >>> should be nuance for ecosystem integrations. >>> >> >> >> This also incentivises intentionally not introducing support for that api >> in older mainlines. We KISS, if the user wants that ecosystem benefit they >> need to upgrade to at least mainline X. >> >> Once older mainlines have it then we have this problem. An alternative >> to the risk of having to always update all the mainlines, is to let the >> ecosystem branch to provide support for the different mainlines as/when >> needed. Both are painful. >> >>
