.
>
> For the rare edge case where we have to stop supporting something entirely
> because it's incompatible with a JDK release (has this happened more than
> the 1 time?) - I think a reasonable fallback is to just not backport new
> JDK support and consider carrying forward the older JDK suppo
> What is the official policy we have around arguments parsing?
From a style point of view I don’t think its something the project has taken a
stance on, its something you define as the author to the CLI you are working on.
> What kind of style should we default to for tools? Posix or Gnu?
From
Great context - thanks for that insight.
Operators running the older supported versions of C* will retain the *option*
to run the older JDK, however if they want to upgrade their JDK version and C*
version *separately* under the above paradigm, they'd need to rev their JDK
separately on their c
Benedict, I am not sure what do you mean by optional feature. FWIW we
cannot compile cassandra-4.1 until we removed the feature in cassandra-5.0.
I, as a user would be very disappointed a feature to be removed in a patch
release.
Yes, replacing nashorn was the unpleasant part. I did not raise the
It’s an additional piece of work. If you need to be able to rebuild this data, then you need the original proposal either way. This proposal to maintain a live updating snapshot is therefore an additional feature on top of the MVP proposed.I don’t think this new proposal is fully fleshed out, I hav
I agree with Blake. These are perfectly reasonable discussions to have up
front.
Snapshot based repair has a huge downside in that you're repairing data
that's days or weeks old. There's going to be issues that arise from that
especially since the deletes that are recorded on the MV aren't going
“I'm curious what this raises for you. “
A few points that come to mind:
- every time we switch/add JDKs we also need to do a bunch of changes in CI
systems, ccm, etc, not only C* - so more work to call out. Also, if we make
older versions support newer JDK, I guess we need to ensure drivers, etc
Depending how long the grid structure takes to build, there is perhaps anyway value in being able to update the snapshot after construction, so that when the repair is performed it is as up to date as possible. But, I don’t think this is trivial? I have some ideas how this might be done but they ar
Yes the issue of Nashorn did spring to mind, but as I recall this was an optional feature. I don’t remember how hard it would have been to simply declare the feature unavailable if you use the newer JDK, but my vague recollection is the hard part was primarily finding a suitable replacement.We may
Lessons learned from advancing JDK support on trunk *should* translate into
older branches making that effort much smaller; Ekaterina you have a lot of
experience here so I'm curious what this raises for you. I like the
productivity implications of us being able to adopt new language features
f
Perhaps we should consider back porting support for newer Java LTS releases to
older C* versions, and suggesting users upgrade JDK first. This way we can have
trunk always on the latest LTS, advancing language feature support more
quickly.
That is, we would have something like
N-2: JDK, JDK-
> 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 is for some assumption of “enough”.
So riffing on this. We could move to something like:
• For each given supported C* br
.
> So yeah. I think we'll need to figure out how much coverage is reasonable
>> to call something "tested". I don't think it's sustainable for us to have,
>> at any given time, 3 branches we test across 3 JDK's each with all our
>> in-jvm test suites is it?
>>
>
Correct.
For non-upgrade test
13 matches
Mail list logo
