Sorry to derail the discussion but just on a point of order, there is actually precedent for requiring a minimum patch level before a major upgrade. For instance, from NEWS.txt:
Upgrade to 3.0 is supported from Cassandra 2.1 versions greater or equal to 2.1.9, or Cassandra 2.2 versions greater or equal to 2.2.2. This approach has also been mentioned [1][2] as a means to introduce a property or setting to disable schema changes and the like before a major upgrade, though in this case it would be optional not required. [1] https://issues.apache.org/jira/browse/CASSANDRA-19556?focusedCommentId=17848544&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17848544 [2] https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata#CEP21:TransactionalClusterMetadata-MigrationPlan > On 31 Jul 2024, at 22:13, C. Scott Andreas <sc...@paradoxica.net> wrote: > > 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 >> <mailto: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 >>> <mailto: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. > > > >