Re: [VOTE] Release Apache Cassandra Java Driver 4.18.0

[Alexandre DUTRA]

+1 (non-binding)

I tested checksums and GPG signatures.

I also built the Cassandra Quarkus extension with the new driver, which is
imho a good test since it also exercises the reactive API. All tests passed
locally:
https://github.com/datastax/cassandra-quarkus/compare/main...adutra:cassandra-quarkus:asf-driver?expand=1

The only caveat for integrators, apart from the GAV coordinates change, is
that 2 dependencies were moved to provided scope: spotbugs-annotations
and jcip-annotations, so these must be provided explicitly.

Thanks,

Alex Dutra

Le sam. 9 déc. 2023 à 08:42, Mick Semb Wever  a écrit :

> Proposing the test build of Cassandra Java Driver 4.18.0 for release.
>
> sha1: 105d378fce16804a8af4c26cf732340a0c63b3c9
> Git: https://github.com/apache/cassandra-java-driver/tree/4.18.0
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1322
>
> 
> The Source release and Binary convenience artifacts are available here:
>
> https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver/4.18.0/
>
> This is the first release post-donation of the Java Driver.  The maven
> coordinates have changed from com.datastax.oss to org.apache.cassandra,
> while all package names remain the same.  There is still work to be done on
> a number of fronts, e.g. being vendor-neutrality, covered
> under CASSANDRA-18611.
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
>
>

Drivers support for Cassandra 4.0

[Alexandre Dutra]

Hi,

The drivers team at DataStax is joining the effort towards releasing
Cassandra 4.0 by
supporting all its new features in recent driver releases. Below is an
update on our
status, more to come as we progress:

* Python driver 3.23.0 was released on April 6th and ships with
support for peers_v2 and
transient replication; protocol v5 is fully implemented, with the exception of
CASSANDRA-14664 (now-in-seconds) [1].

* Java drivers 3.9.0 and 4.6.0 will be released in the next few weeks.
They will include
support for missing features (transient replication and
now-in-seconds), effectively
providing complete support for protocol v5 in its current state. To
make it as easy as
possible for users to adopt C* 4.0, we decided to release both major
branches of the Java
driver, including 3.x, even if this branch is now in maintenance mode.

* C# driver 3.15.0 is planned for sometime in May; it should include
support for peers_v2,
transient replication, and a fairly comprehensive set of protocol v5 features.

* Other drivers may follow this year.

Note that until CASSANDRA-14973 [2] is merged, all drivers consider
protocol v5 as beta.
This means that users need to explicitly allow usage of beta protocols
in their drivers
before they can connect with v5.

Also note that CASSANDRA-15299 [3] is expected to change protocol v5
radically. Currently,
drivers do not use any form of checksumming technique when connecting
with v5. If anyone
is able to bump that ticket in priority we will certainly appreciate
it on the drivers
side so we can complete the implementation.

If there is anything else that we could do to help in getting Cassandra 4.0 out,
please let us know.

Thanks,

Alexandre Dutra

[1] https://issues.apache.org/jira/browse/CASSANDRA-14664
[2] https://issues.apache.org/jira/browse/CASSANDRA-14973
[3] https://issues.apache.org/jira/browse/CASSANDRA-15299

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

[DISCUSS] CEP-8 Drivers Donation

[Alexandre Dutra]

Hi,

As per the CEP process guidelines, I'm starting a formal DISCUSS
thread to resume the conversation
started here[1].

On behalf of the developers who maintain the DataStax drivers, I
confirm that we are offering to
donate to the Apache Software Foundation all seven DataStax-funded
drivers, and are therefore
opening this CEP[2] to discussion.

In the CEP document linked above, we tried our best to address all the
issues that we anticipate
going forward with this endeavor, but the task is big: your
suggestions, remarks and comments are
most welcome.

As stated previously, we understand that we're all primarily focused
on the C* 4.0 release
currently; therefore we don't mind deferring any concrete progress on
this until after C* 4.0 is
out.

However, as you can judge from the CEP draft document, the donation is
likely to have many
implications on sensitive areas, e.g. on project governance; which is
why we think best to open the
discussion as early as possible, so that we all have enough time to
determine what we think best
suits the project going forward.

Kind regards,

Alex Dutra

[1] 
https://lists.apache.org/thread.html/ra7caa1dd42ccaa04bcabfbc33233995c125c655f9a3cdb2c7bd8e9f7%40%3Cdev.cassandra.apache.org%3E
[2] 
https://docs.google.com/document/d/1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY/edit?usp=sharing

-- 
Alexandre Dutra
alexandre.du...@datastax.com

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] CEP-8 Drivers Donation

[Alexandre Dutra]

Hi Dinesh,

While we think that maintaining the drivers together as a long-term goal
would be beneficial as it would allow the drivers to evolve together and
adopt similar design decisions, we also understand that donating 7 drivers
at once may put the whole operation at risk, as some folks here already
pointed out.

The current CEP text actually advocates for a phased approach (see
"Approach" section):

[...] the donation process will be iterative, and will start with only the
> Java driver in a first phase; then, in a second phase, it will be extended
> to the remaining drivers.
> Once the Java driver is transferred, and before the others are
> transferred, we will revise the methodology described in this CEP, and if
> necessary, revise its parameters and adjust them accordingly. A second CEP
> may be required if the changes to the methodology are found to be
> substantial.
>

What do you think of this idea, does it sound reasonable ?

Thanks,

Alex

On Mon, Jul 27, 2020 at 11:53 PM Dinesh Joshi  wrote:

> Alexandre,
>
> I gave the document a quick read and TL;DR seems to be that we'd like to:
>
> 1. Bring in all drivers
> 2. They're part of the C* project
>
> If so, I would prefer if we add the Java driver first to the project.
> Based on that experience we can move forward with other drivers. However, I
> am open to the idea of adding all the drivers to the project.
>
> Please correct me if I misunderstood something.
>
> Thanks,
>
> Dinesh
>
> > On Jul 26, 2020, at 8:41 PM, Nate McCall  wrote:
> >
> > This is fantastic, Alexandre, thanks for putting this together!
> >
> > I put an initial set of comments/concerns on there and will loop back
> later
> > this week after other folks have  a go.
> >
> > Cheers,
> > -Nate
> >
> > On Sat, Jul 25, 2020 at 7:35 AM Alexandre Dutra <
> > alexandre.du...@datastax.com> wrote:
> >
> >> Hi,
> >>
> >> As per the CEP process guidelines, I'm starting a formal DISCUSS
> >> thread to resume the conversation
> >> started here[1].
> >>
> >> On behalf of the developers who maintain the DataStax drivers, I
> >> confirm that we are offering to
> >> donate to the Apache Software Foundation all seven DataStax-funded
> >> drivers, and are therefore
> >> opening this CEP[2] to discussion.
> >>
> >> In the CEP document linked above, we tried our best to address all the
> >> issues that we anticipate
> >> going forward with this endeavor, but the task is big: your
> >> suggestions, remarks and comments are
> >> most welcome.
> >>
> >> As stated previously, we understand that we're all primarily focused
> >> on the C* 4.0 release
> >> currently; therefore we don't mind deferring any concrete progress on
> >> this until after C* 4.0 is
> >> out.
> >>
> >> However, as you can judge from the CEP draft document, the donation is
> >> likely to have many
> >> implications on sensitive areas, e.g. on project governance; which is
> >> why we think best to open the
> >> discussion as early as possible, so that we all have enough time to
> >> determine what we think best
> >> suits the project going forward.
> >>
> >> Kind regards,
> >>
> >> Alex Dutra
> >>
> >> [1]
> >>
> https://lists.apache.org/thread.html/ra7caa1dd42ccaa04bcabfbc33233995c125c655f9a3cdb2c7bd8e9f7%40%3Cdev.cassandra.apache.org%3E
> >> [2]
> >>
> https://docs.google.com/document/d/1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY/edit?usp=sharing
> >>
> >> --
> >> Alexandre Dutra
> >> alexandre.du...@datastax.com
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
Alexandre Dutra
e. alexandre.du...@datastax.com
w. www.datastax.com

Re: [DISCUSS] CEP-8 Drivers Donation

[Alexandre Dutra]

Hi Alex and Jeremy,

We've been thinking of the driver codebase on a repository level in the
CEP, which is why we do not mention any specific branch. To clarify, our
intention is to donate the entire repository, including all existing
commits, branches and tags. So don't worry: the Java driver 3.x branch
would naturally be part of the donation. I will include a sentence in the
CEP to make this statement explicit.

Thanks,
Alex

On Tue, Aug 4, 2020 at 8:30 PM Jeremy Chapman 
wrote:

> +1 on both starting with just the Java driver first and contributing all
> 3.x and 4.x branches. Some of our long-running apps may continue using 3.x
> for quite a while simply due to the extra effort due to their
> deep-maintenance lifestyle.
>
> -Jeremy
>
> On Tue, Aug 4, 2020 at 4:26 AM Oleksandr Petrov <
> oleksandr.pet...@gmail.com>
> wrote:
>
> > I've tried to find this information in the document above, but couldn't
> > find an explicit mention of it, possibly because it's implied. If we take
> > java-driver as an example, is this CEP proposing to contribute all
> branches
> > (3.x and 4.x) or only the latest one?
> >
> > Thank you,
> > -- Alex
> >
> > On Wed, Jul 29, 2020 at 12:16 PM Alexandre Dutra <
> > alexandre.du...@datastax.com> wrote:
> >
> > > Hi Dinesh,
> > >
> > > While we think that maintaining the drivers together as a long-term
> goal
> > > would be beneficial as it would allow the drivers to evolve together
> and
> > > adopt similar design decisions, we also understand that donating 7
> > drivers
> > > at once may put the whole operation at risk, as some folks here already
> > > pointed out.
> > >
> > > The current CEP text actually advocates for a phased approach (see
> > > "Approach" section):
> > >
> > > [...] the donation process will be iterative, and will start with only
> > the
> > > > Java driver in a first phase; then, in a second phase, it will be
> > > extended
> > > > to the remaining drivers.
> > > > Once the Java driver is transferred, and before the others are
> > > > transferred, we will revise the methodology described in this CEP,
> and
> > if
> > > > necessary, revise its parameters and adjust them accordingly. A
> second
> > > CEP
> > > > may be required if the changes to the methodology are found to be
> > > > substantial.
> > > >
> > >
> > > What do you think of this idea, does it sound reasonable ?
> > >
> > > Thanks,
> > >
> > > Alex
> > >
> > > On Mon, Jul 27, 2020 at 11:53 PM Dinesh Joshi 
> wrote:
> > >
> > > > Alexandre,
> > > >
> > > > I gave the document a quick read and TL;DR seems to be that we'd like
> > to:
> > > >
> > > > 1. Bring in all drivers
> > > > 2. They're part of the C* project
> > > >
> > > > If so, I would prefer if we add the Java driver first to the project.
> > > > Based on that experience we can move forward with other drivers.
> > > However, I
> > > > am open to the idea of adding all the drivers to the project.
> > > >
> > > > Please correct me if I misunderstood something.
> > > >
> > > > Thanks,
> > > >
> > > > Dinesh
> > > >
> > > > > On Jul 26, 2020, at 8:41 PM, Nate McCall 
> wrote:
> > > > >
> > > > > This is fantastic, Alexandre, thanks for putting this together!
> > > > >
> > > > > I put an initial set of comments/concerns on there and will loop
> back
> > > > later
> > > > > this week after other folks have  a go.
> > > > >
> > > > > Cheers,
> > > > > -Nate
> > > > >
> > > > > On Sat, Jul 25, 2020 at 7:35 AM Alexandre Dutra <
> > > > > alexandre.du...@datastax.com> wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> As per the CEP process guidelines, I'm starting a formal DISCUSS
> > > > >> thread to resume the conversation
> > > > >> started here[1].
> > > > >>
> > > > >> On behalf of the developers who maintain the DataStax drivers, I
> > > > >> confirm that we are offering to
> > > > >> donate to the Apache Software Foundation all seven

Re: [VOTE] Release Apache Cassandra Java Driver 3.12.0 (2nd attempt)

[Alexandre DUTRA]

+1 (nb)


Le jeu. 9 janv. 2025 à 17:21, Sylwester Lachiewicz 
a écrit :

> +1(nb)
>
> czw., 9 sty 2025, 17:13 użytkownik Josh McKenzie 
> napisał:
>
>> +1
>>
>> On Wed, Jan 8, 2025, at 11:59 PM, Tolbert, Andy wrote:
>>
>> +1 (nb)
>>
>> On Wed, Jan 8, 2025 at 8:22 PM Chris Lohfink 
>> wrote:
>>
>> +1
>>
>> On Wed, Jan 8, 2025 at 4:14 PM Bret McGuire 
>> wrote:
>>
>> Greetings all!
>>
>>I’m proposing the Cassandra Java Driver 3.12.0 for release.  This
>> represents a second attempt at releasing this version; an earlier attempt
>> failed due to a staging issue.
>>
>> sha1: 1a96d27130ea43ed5762c4f7b7cc182eb24f8952
>>
>> git: *https://github.com/apache/cassandra-java-driver/tree/3.x*
>> 
>>
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1354
>>
>>The Source release is available here:
>>
>> *https://dist.apache.org/repos/dist/dev/cassandra/cassandra-java-driver/3.12.0/
>> *
>>
>>To recap: this is the first release of the 3.x Java driver since its
>> donation.  This release is nearly identical to the last DataStax release (
>> *3.11.5*
>> ).
>> The full changelog can be found at
>> *https://github.com/apache/cassandra-java-driver/tree/3.x/changelog#3120*
>> 
>>
>>The vote will be open for 72 hours (longer if needed).  Everyone who
>> has tested the build is invited to vote. Votes by PMC members are
>> considered binding. A vote passes if there are at least three binding +1s
>> and no -1's.
>>
>>Thanks!
>>
>>
>> - Bret -
>>
>>
>>

Re: Welcome Abe Ratnofsky as Cassandra committer!

[Alexandre DUTRA]

Congrats Abe!

Le lun. 12 mai 2025 à 14:26, Francisco Guerrero  a
écrit :

> Congrats Abe!
>
> On 2025/05/12 16:45:22 Alex Petrov wrote:
> > Hello folks of the dev list,
> >
> > The Apache Cassandra PMC is very glad to announce that Abe Ratnofsky has
> accepted our invitation to become a committer!
> >
> > Abe has been actively contributing to Cassandra itself, made outstanding
> contributions to the Cassandra drivers, played a key role in the recently
> accepted CEP-45 [1], and has been active in the community — including on
> this mailing list and on Cassandra conferences and meetups.
> >
> > Please join us in congratulating and welcoming Abe!
> >
> > Alex Petrov
> > on behalf of the Apache Cassandra PMC
> > [1]
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking
>

Re: Welcome Bret McGuire as Cassandra PMC Member!

[Alexandre DUTRA]

Great news, and so well deserved! Congratulations Bret!

Le ven. 16 mai 2025 à 19:00, Jeremiah Jordan  a écrit :

> Congrats Bret!
>
> On May 16, 2025 at 4:00:12 PM, Mick Semb Wever  wrote:
>
>>
>> The Project Management Committee (PMC) for Apache Cassandra is delighted
>> to announce that Bret McGuire has joined the PMC!  Thank you Bret for
>> all your contributions to the project over the years, especially with so
>> many of the drivers.
>>
>> The PMC - Project Management Committee - manages and guides the
>> direction of the project, and is responsible for inviting new committers and
>>  PMC members to steward the longevity of the project.  See
>> https://community.apache.org/pmc/responsibilities.html if you're
>> interested in learning more about the rights and responsibilities of PMC
>> members.
>>
>> Please join us in welcoming Bret McGuire to his new role in our project!
>>
>> Mick, on behalf of the Apache Cassandra PMC
>>
>