Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

2023-10-04 Thread Maxim Muzafarov
Hello everyone, Posting the thread update. We have merged the issue into trunk and 5.0, so basically there should be no problems and backwards compatibility issues. I'd like to thank all of you for your cooperation and I'm happy to see this update will be in use soon. https://issues.apache.org/ji

Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

2023-07-27 Thread Josh McKenzie
+1 to the change pre 5.0. Any committers have bandwidth to review https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-14667? PR can be found here: https://github.com/apache/cassandra/pull/2238/files On Thu, Jul 27, 2023, at 7:59 AM, Maxim Muzafarov wrote: > Bump this topic up for

Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

2023-07-27 Thread Maxim Muzafarov
Bump this topic up for visibility as the code freeze is coming soon. This seems like a good change to include in 5.0 as this kind of library upgrade is more natural when the major version changes. It is still possible to postpone it to 6.0, but the main concern here is that the current version of

Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

2023-07-21 Thread Maxim Muzafarov
Hello everyone, It still needs a pair of eyes to push it forward. I came across another good thing that might help us to overcome the difficulties with the dropwizard metrics dependency upgrade. The change relates to the driver itself and reuses the same approach that was used to deal with the d

Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

2023-07-03 Thread Maxim Muzafarov
I'd like to mention the approach we took here: to untangle the driver update in tests with the dropwizard library version (cassandra-driver 3.11 requires the "old" JMXReporter classes in the classpath) we have copied the classes into the tests themselves, as it is allowed by the Apache License 2.0.

Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

2023-06-28 Thread Bowen Song via dev
IMHO, anyone upgrading software between major versions should expect to see breaking changes. Introducing breaking or major changes is the whole point of bumping major version numbers. Since the library upgrade need to happen sooner or later, I don't see any reason why it should not happen in

Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

2023-06-28 Thread Josh McKenzie
Reasons 1 and 2 (getting into CVE coverage pipeline proactively rather than reactively, JDK consistency) seem compelling enough to justify the upgrade on their own to me. > This is a problem for applications/tools that rely on the cassandra > classpath (lib/jars) as after the upgrade they may be

[DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

2023-06-27 Thread Maxim Muzafarov
Hello everyone, We use the Dropwizard Metrics 3.1.5 library, which provides a basic set of classes to easily expose Cassandra internals to a user through various interfaces (the most common being JMX). We want to upgrade this library version in the next major release 5.0 up to the latest stable 4