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.

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

Reply via email to