For the purpose of a quick straw poll, I’m not opposed to backporting to 5.x, but I don’t support backporting to 4.x-series releases for the compatibility and upgrade complexity reasons previously discussed.
- Scott > On Jan 12, 2026, at 1:27 AM, Štefan Miklošovič <[email protected]> wrote: > > 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. >>>>> >>>>>
