When I worked on Riak we had a much more complex matrix due to supporting
even more backwards compatibility. It’s not unfeasible. You don’t have to
run every suite on every commit since as folks have pointed out for the
most part the JVM isn’t culprit. Need to run it enough times to catch when
it i
> The problem with (2) being only "overlapping JDK version support on
> consecutive releases" instead of an overlapping JDK over all `N-2` releases
> is that we say we support upgrade paths that we never test (w/
> jvm-dtest-upgrade). Here, I would rather add a third LTS JDK to a release to
>
On Tue, May 20, 2025 at 08:12 Josh McKenzie wrote:
> This came up in the release versioning thread and we punted to its own
> thread.
>
> *Topic: How do we want to handle JDK version support in C* releases?*
>
> Oracle LTS policy here:
> https://www.oracle.com/java/technologies/java-se-support-ro
Another thing to consider is the usage of JDK internals. The JDK developers
do not promise backward compatibility for internals. We still have things
like jamm that need updates, and not only jamm. Sometimes they can fail us
silently despite fully green CI.
Performance is a good point - we don’t e
I've written a few dozen tools over the years and have been happy with
JCommander. Picocli looks to follow pretty much all the same conventions,
but has a few nicer features on top. I'd love to see the entire project
standardize on it.
On Tue, May 20, 2025 at 2:29 AM Štefan Miklošovič
wrote:
>
There are performance differences between JVMs. I agree that bug testing of JVM versions for clients is not very important, but isolating JVM characteristic changes from database characteristic changes is important, for me at least.On 20 May 2025, at 17:47, Jon Haddad wrote:If you're upgrading an
.
> If it came down to either:
>
>1. Support latest 2 LTS JDK on any given C* release, no overlap.
>Operators deal with it.
>2. Require 1 overlapping JDK version support on consecutive releases.
>Users may have to wait a year for new JDK features
>
>
My opinions…
- we sho
More questions and thoughts...
* Consistency question: In the case where a base table gets a corrupt
SSTable and is scrubbed, when it repairs against the view, without tracking
the deletes against the secondary table, do we end up pushing the lack of
data into the MV?
* I threw out the idea earli
Thanks everyone, and thanks Jon for contributing and continuing to enhance
easy-cass-stress (now cassandra-easy-stress). It’s an incredibly valuable
addition to the community.
Doug
> On May 19, 2025, at 6:13 PM, Paulo Motta wrote:
>
> Nice work, congrats to all involved! 🎉
>
> On Mon, May 19
> This gets stated on perhaps an annual basis, so perhaps we should start
> having these conversations on wiki to avoid the repetition.
I didn't state this in my original email: my goal is to come to a consensus and
codify it in the wiki going forward.
> * or do the two version thing and not bot
If you're upgrading an environment without doing any additional testing -
sure, it can be helpful to isolate the issue.
However, outside of this scenario, where you actually test your upgrade
process and vet the functionality, I don't see it as a big gain - certainly
not enough of one to hold the
On Tue, May 20, 2025 at 10:59 AM Jon Haddad wrote:
> > There is also that recommendation that I keep on hearing - don’t do C*
> > major upgrade and JDK upgrade simultaneously. I believe that was one of the
> > reasons for overlap too
>
> There's no practical reason for this today. Maybe in the
While I understand *some* users care, we shouldn't take the preferences of
a very small minority of users as project policy. I've worked with
hundreds of teams, and I can't recall a single one caring about doing A/B
testing in JVM versions.
> There is also that recommendation that I keep on heari
In-jvm dtests need to execute an upgrade path on a single jvm, but this is close to always possible on the latest jvm. We haven’t hit any issues that I know of in this respect during any version change, so I don’t think this is a real concern.Some users do care about overlapping JVM compatibility.
There is also that recommendation that I keep on hearing - don’t do C*
major upgrade and JDK upgrade simultaneously. I believe that was one of the
reasons for overlap too
On Tue, 20 May 2025 at 11:36, Jon Haddad wrote:
> There’s no “leaving users in the lurch” by requiring JDK upgrades.
>
> If u
There’s no “leaving users in the lurch” by requiring JDK upgrades.
If users are using containers (pretty much everyone i talk to) then the JDK
is included, versions don’t matter.
If not, every modern Linux distro supports multiple installed JDKS. Again,
not a problem.
So far the only convincing
This came up in the release versioning thread and we punted to its own thread.
*Topic: How do we want to handle JDK version support in C* releases?*
Oracle LTS policy here:
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
My first rough thoughts:
1. Any given C* release wi
Hey,
I mapped what command line parser styles we use across the project while
dealing with some ticket (20448) and it is mixed like this, I am talking
about stuff we use in commons-cli for Gnu and Posix parsers:
GnuParser
StandaloneSplitter
BulkLoader (aka sstableloader)
HashPassword
GenerateTok
18 matches
Mail list logo
