There are a few things unclear to me in this thread and the ticket, and details in the Jira are slim. Yifan / others
supportive of backporting this feature, could you help me answer these questions? – What's this for? I'd appreciate a
detailed explanation of what "Enhance CQLSSTableWriter to notify clients on sstable production" does and
how it's meant to be used. Why is it needed for rolling upgrades? The phrasing of the ticket right now reads as
nice-to-have rather than must-have. An earlier email described the value as "code quality and brings other
benefits," but I'd expect the standard for feature backports to be higher. – What's not possible if this isn't
backported? What experience suffers today for lack of it / what problem does it solve? And what is the
alternative/fallback if others are not supportive of backport? – If this is deemed required for upgrade, that means
users of previous releases would have to first upgrade to the latest release on their current train before upgrading
to the latest major version. This is not a pattern that has been required in the past, and we should not introduce
such a requirement. Do you intend this to be the required path for 4.1.x upgrades to 5.x+? My general thoughts: – The
patch is small and the feature is small so I don't have much concern with a backport; zero-ish vote. – It definitely
shouldn't block release of the current 4.1.x vote thread that's in progress. – We shouldn't introduce upgrade paths
that require users to upgrade to at-minimum-patchlevel versions of current releases before upgrading to future
majors; I'm -1 on that. Thanks, – Scott On Jul 31, 2024, at 2:04 PM, Jon Haddad <j...@jonhaddad.com> wrote: 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.
