Hi everybody, I want to refresh this thread after the holidays. Is there an agreement we reached? Is everybody on board with backporting to 4.1+? How are we going to do this concretely? I guess Jaydeep would be involved in the backporting as he just said. I honestly do not think there is anybody else better suited to make it happen and your willingness to do that is really appreciated.
Regards On Tue, Dec 23, 2025 at 5:38 AM Jaydeep Chovatia <[email protected]> wrote: > > FYI—regardless of the outcome, you can count on me to port CEP-37 in whatever > form the community agrees on. As mentioned earlier, I’m already maintaining a > private 4.1.6 fork (https://github.com/apache/cassandra/pull/3367). > Thank you! > > Jaydeep > > On Mon, Dec 22, 2025 at 7:43 AM Micah Green <[email protected]> wrote: >> >> I'm really interested in this thread, but don't see an update on where we >> landed in terms of backporting and also the amount of work involved. I'm >> all for backporting to 5.x minimally! I'm planning our 2026 work and where >> this discussion goes will really help me optimally plan, which is why I'm >> asking. >> Thanks! >> >> On Sun, Dec 7, 2025 at 4:44 PM Ekaterina Dimitrova <[email protected]> >> wrote: >>> >>> Seems like the 4.1 branch would still require some work to cover everything >>> raised on this thread? Have anyone evaluated how much work that can be? >>> >>> I agree porting to 4.1, but not 4.0 is kind of weird. Then probably we >>> better have it only in 5.0? >>> >>> Do people think it makes sense to create some kind of user survey around >>> this work, too? Posted in @user >>> >>> On Fri, 5 Dec 2025 at 9:00, Josh McKenzie <[email protected]> wrote: >>>> >>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and backporting >>>> to both would increase the risk and maintenance burden. >>>> >>>> It would but by how much? >>>> >>>> 2 things jump out to me re: risk and maintenance: >>>> >>>> Risk: We kind of need to tackle the "version straddle w/schema table diffs >>>> is currently Bad and makes rollbacks manual and brittle" broadly; this >>>> feature is just one more example of that though it's a little exacerbated >>>> by discussing doing something like this in a patch release. The ergonomics >>>> of the "one-way-door without a human manually deleting columns" part holds >>>> true cross-MAJOR too. "Progress" here seems like it's either we handle >>>> this on a case-by-case basis w/flags to remove those schema entries on >>>> rollback (kinda ew), or more durably with an elegant solution in the long >>>> term, i.e. capabilities framework, though that doesn't answer the "we >>>> explode when schemas don't match" bit. >>>> >>>> Maintenance: maintaining this across 4 branches is clearly more toil than >>>> across 2. >>>> >>>> I'm personally kind of keen for us to tackle that Risk bit; I'd like all >>>> of us to be able to more freely consider making changes to schema tables >>>> w/out the complexity burden we have right now and the operator toil and >>>> risk that comes along with it. >>>> >>>> The maintenance toil bit - I have less opinions on. Kind of depends on how >>>> many people are on 4.0/4.1 right now that we'd expect to be on 4.1 for >>>> another year until 7.0 hits and whether we think they'd benefit from the >>>> feature (and contribute to bettering it) during that year I guess. >>>> >>>> On Thu, Dec 4, 2025, at 5:57 PM, Paulo Motta wrote: >>>> >>>> Otherwise it feels weird backporting to 4.1 but not 4.0, and backporting >>>> to both would increase the risk and maintenance burden. >>>> >>>>
