I think the current guidelines are sensible.
Going through your suggestions:
1) I think this is already the case, more or less. We are not doing perf
changes in older branches. This is what we see in CASSANDRA-19429, a user
reported that it is a performance improvement, and most probably he is
ri
+1
On Thu, Jan 23, 2025, at 9:58 AM, Štefan Miklošovič wrote:
> +1
>
> On Sat, Jan 18, 2025 at 10:54 PM Bret McGuire wrote:
>> Greetings all!
>>
>>
>>I’m proposing the Cassandra Java Driver 3.12.1 for release.
>>
>>
>> sha1: 873e6f764a499bd9c5a42cafa53dc77184711eea
>>
>> git: https://gi
Hi Stefan,
Thank you a lot for the detailed feedback! Few comments:
>> I think this is already the case, more or less. We are not doing perf
changes in older branches.
Yes, I understand the idea about stability of older branches, the primary
issue for me is that if I contribute even a small impro
>> That is ... 6 branches at once. We were there, 3.0, 3.11, 4.0, 4.1, 5.0,
trunk. If there was a bug in 3.0, because we were supporting that, we had
to put this into 6 branches
My idea is not to increase the number of support branches (it is
definitely not what I want to, I am more a fan of releas
On Thu, Jan 23, 2025 at 3:20 PM Dmitry Konstantinov
wrote:
> Hi Stefan,
>
> Thank you a lot for the detailed feedback! Few comments:
>
> >> I think this is already the case, more or less. We are not doing perf
> changes in older branches.
> Yes, I understand the idea about stability of older bran
+1
On Sat, Jan 18, 2025 at 10:54 PM Bret McGuire
wrote:
> Greetings all!
>
>I’m proposing the Cassandra Java Driver 3.12.1 for release.
>
> sha1: 873e6f764a499bd9c5a42cafa53dc77184711eea
>
> git: https://github.com/apache/cassandra-java-driver/tree/3.12.1
>
> Maven Artifacts:
> https://repos
> Of note, it's been 13 months since 5.0 GA. :)
On a scale of 1-10, I'm a 10 out of 10 for being wrong here. It's been 13
months *since we initially intended to release 5.0*. Stabilization of CI and
some bugs took us to mid 2024. So it's not as bad as all that. Thanks to those
that pointed this
For commit log archiving we already have the concept of “commands” to be
executed. Maybe a similar concept would be useful for snapshots? Maybe a
new “user snapshot with command” nodetool action could be added. The
server would make its usual hard links inside a snapshot folder and then it
could
I feel uneasy about executing scripts from Cassandra. Jon was talking about
this here (1) as well. I would not base this on any shell scripts /
commands executions. I think nothing beats pure Java copying files to a
directory ...
(1) https://lists.apache.org/thread/jcr3mln2tohbckvr8fjrr0sq0syof080
+1 (nb)
On Thu, 23 Jan 2025 at 16:35, Josh McKenzie wrote:
>
> +1
>
> On Thu, Jan 23, 2025, at 9:58 AM, Štefan Miklošovič wrote:
>
> +1
>
> On Sat, Jan 18, 2025 at 10:54 PM Bret McGuire wrote:
>
> Greetings all!
>
>
>I’m proposing the Cassandra Java Driver 3.12.1 for release.
>
>
> sha1: 873
Wahoo! Congratulations Patrick!
-Joey
On Wed, Jan 22, 2025 at 11:06 AM Jordan West wrote:
> The PMC's members are pleased to announce that Patrick McFadin has accepted
> an invitation to become a PMC member.
>
> Thanks a lot, Patrick, for everything you have done for the project all
> these yea
Interesting, I will need to think about it more. Thanks for chiming in.
On Wed, Jan 22, 2025 at 8:10 PM Blake Eggleston
wrote:
> Somewhat tangential, but I’d like to see Cassandra provide a backup story
> that doesn’t involve making copies of sstables. They’re constantly
> rewritten by compactio
With four +1 votes (3 binding) and zero -1 votes the vote passes.
Thanks all!
- Bret -
On Thu, Jan 23, 2025 at 11:42 AM Maxim Muzafarov wrote:
> +1 (nb)
>
> On Thu, 23 Jan 2025 at 16:35, Josh McKenzie wrote:
> >
> > +1
> >
> > On Thu, Jan 23, 2025, at 9:58 AM, Štefan Miklošovič wrote:
13 matches
Mail list logo
