Any change we bring to stable releases, even though it is non-user facing change, brings in the possibility of introducing bugs and / or unintended side effects. Therefore it is important to carefully consider the trade offs when we make changes to older releases. We also have a precedent to make changes to older releases for testing.
In this particular case Yifan's patch is touching a fairly isolated class and presents a low risk. The benefit here is that the analytics sub-project would avoid additional work arounds for Cassandra 4 & 4.1. I am fine with granting an exception for backporting to 4.1 and 4.0 in this case. thanks, Dinesh On Tue, Jul 30, 2024 at 9:52 AM Yifan Cai <yc25c...@gmail.com> wrote: > Here is my 2 cents. Maybe we need to differentiate the user-facing > improvements and ecosystem-internal improvements, or have a discussion > about it. > I guess when the current policy of "improvements and new features on trunk > only" was made, it was to target the user-facing improvements. The internal > changes are not exposed to cassandra users directly. > As Josh pointed out, with more projects (sidecar and analytics have > dependency on cassandra public interface) in the ecosystem, we are more > likely to encounter the scenarios where we want to modify the mainline > branches for integration purposes. > > The downside of preventing the integration updates to the older branches > is having different solutions per Cassandra version in the other projects > under the Cassandra umbrella. It is a maintenance pain and potentially > causes errors. It is my original motivation of backporting the patch to the > other branches. > > - Yifan > > On Tue, Jul 30, 2024 at 6:04 AM Josh McKenzie <jmcken...@apache.org> > wrote: > >> Some thoughts: >> >> 1. Most of our PMC votes are majority-based, not binding -1. So Jeff >> being -1 doesn't mean the whole PMC being -1. So don't take his -1 as >> being >> a show stopper or indicative of everyone on the PMC (and don't take me >> saying this as the converse ;)) >> 2. I expect we have a lot of debt when it comes to our ecosystem >> integrations on older branches. Bringing those projects into the ASF >> umbrella and into the project ecosystem is at odds with a hard policy of >> "we don't add improvements or new features to old branches", >> *specifically* in cases like this where the desire is to get uniform >> support for ecosystem projects across all supported branches of C* >> 3. 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. >> 4. To Jeff's point: everyone is always going to have some minor >> improvement they'd like to back-port to older branches. >> >> I haven't thought deeply enough about this specific situation to have a >> well formed opinion, but figured calling out the above things is worth >> doing. This probably won't be the last time we look at our supported >> branches and have some pain we'd like to address based on the inconsistent >> ecosystem support and API piece across them. >> >> On Mon, Jul 29, 2024, at 1:32 PM, Yifan Cai wrote: >> >> It sounds like we are all good with backporting to 5.0. >> >> Thank you all for the feedback. >> >> - Yifan >> >> On Fri, Jul 26, 2024 at 12:21 PM Jeff Jirsa <jji...@gmail.com> wrote: >> >> >> >> >> On Jul 26, 2024, at 11:09 AM, Yifan Cai <yc25c...@gmail.com> wrote: >> >> >> Thanks Jeff for restating the policy. >> >> According to the release lifecycle doc >> >> >> - Missing features from newer generation releases are back-ported on >> per - PMC vote basis. >> >> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle >> >> We do not have a policy to prevent new features strictly for the branches >> in maintenance state. >> >> IMO, the patch qualifies as the missing feature. (As said, it is useful >> for Cassandra Analytics, and it is good to have the same bridge >> implementation amongst different cassandra versions) >> >> Therefore, I would like to call for a vote. >> >> >> Sure >> >> I’m -1 on 4.0 and 4.1 >> >> - Jeff >> >> >> On Fri, Jul 26, 2024 at 10:25 AM Jeff Jirsa <jji...@gmail.com> wrote: >> >> Everyone has a low risk change they want to backport to every branch, 4.0 >> and 4.1 in particular are way past the point we should be adding features >> >> The policy exists and it’s a pure feature not a regression >> >> >> >> >> >> > On Jul 26, 2024, at 9:59 AM, Brandon Williams <dri...@gmail.com> wrote: >> > >> > Given how low risk this is, I don't see an issue with backporting it >> > and I'm sure the usefulness outweighs what risk there is. +1 (5.0.1 >> > though, not 5.0.0) >> > >> > Kind Regards, >> > Brandon >> > >> >> On Fri, Jul 26, 2024 at 11:52 AM Yifan Cai <yc25c...@gmail.com> wrote: >> >> >> >> Hi everyone, >> >> >> >> CASSANDRA-19800 is currently in the state of ready to be committed. >> Before that, I want to propose backporting it to 4.0, 4.1 and 5.0. >> >> >> >> The ability to notify CQLSSTableWriter user when new sstables are >> produced is especially useful for Cassandra Analytics and other consumers. >> The API is more reliable than monitoring the file directory. >> >> >> >> That being said, I am aware that the patch is an improvement and trunk >> only. I want to ask for an exemption on backporting the patch for two >> reasons. It is useful for Cassandra Analytics. The patch is low risk for >> Cassandra server as it only touches CQLSSTableWriter, which is only used by >> toolings. >> >> >> >> - Yifan >> >> >>
