I've realized that, although a vote is called, I forgot to create the
voting thread. I apologize for the oversight.
It looks like there's been no further discussion on this topic, so I'll go
ahead and set up a dedicated voting thread for the backport proposal
shortly.
Please vote once it is up.
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 version
Hi Scott,
– 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
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 not
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 wrote:
> Hi
On Tue, Jul 30, 2024 at 11:47 AM Mick Semb Wever wrote:
> 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
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 trad
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 ne
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 c
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
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 de
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 wrote:
>
>
> On Jul 26, 2024, at 11:09 AM, Yifan Cai wrote:
>
>
> Thanks Jeff for restating the policy.
>
> According to the release lifecycle doc
>
>>
On Jul 26, 2024, at 11:09 AM, Yifan Cai wrote:Thanks Jeff for restating the policy.According to the release lifecycle docMissing 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
Hi Jeremiah,
It is an interesting idea. As of now, I think it is too much of a risk (or
not feasible at all) to only use 5.0/trunk Cassandra-all dependency in
Cassandra Analytics, since it depends on other components in Cassandra.
- Yifan
I thought the server now has the ability to write out old sstable versions? So you could use the CQLSSTableWriter from 5.0/trunk to write out sstables 4.0 can read?On Jul 26, 2024, at 1:07 PM, Yifan Cai wrote:
Caution: The sender name (Yifan Cai) is different from their email addr
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 f
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 wrote:
>
> Given how low risk thi
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 wrote:
>
> Hi everyone,
>
> CASSANDRA-19800 is currently in the state of re
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
19 matches
Mail list logo
