Yeah, we have a fork of Cassandra with custom patches, and a fork of dtest
with some additional custom tests, so we will have to upgrade dtest as
well.
Is there any specific tag of dtest we should use or the latest trunk is
fine to test against 3.0.27?
Jaydeep
On Mon, Jun 13, 2022 at 10:51 PM C.
If you have a fork of Cassandra with custom patches and build/execute the dtest
suite as part of qualification, you’d want to upgrade that as well.
Note that in more recent 3.0.x releases, the project also introduced in-JVM
dtests. This is a new suite that serves a similar purpose to the Python
Thanks Jeff and Scott for valuable feedback!
One more question, do we have to upgrade the dTest repo if we go to 3.0.27,
or the one we have currently already working with 3.0.14 should continue to
work fine?
Jaydeep
On Mon, Jun 13, 2022 at 10:25 PM C. Scott Andreas
wrote:
> Thank you for
Thank you for reaching out, and for planning the upgrade!
Upgrading from 3.0.14 to 3.0.27 would be best, followed by upgrading to 4.0.4.
3.0.14 contains a number of serious bugs that are resolved in more recent 3.0.x
releases (3.0.19+ are generally good/safe). Upgrading to 3.0.27 will put you
The versions with caveats should all be enumerated in
https://github.com/apache/cassandra/blob/cassandra-3.0/NEWS.txt
The biggest caveat was 3.0.14 (which had the fix for cassandra-13004),
which you're already on.
Personally, I'd qualify exactly one upgrade, and rather than doing 3
different
Hi,
I am running Cassandra version 3.0.14 at scale on thousands of nodes. I am
planning to do a minor version upgrade from 3.0.14 to 3.0.26 in a safe
manner. My eventual goal is to upgrade from 3.0.26 to a major release 4.0.
As you know, there are multiple minor releases between 3.0.14 and
