Re: Should we cut some new releases?

+1 On 13/3/23 21:25, Jacek Lewandowski wrote: +1 pon., 13 mar 2023, 20:36 użytkownik Miklosovic, Stefan napisał: Yes, I was waiting for CASSANDRA-18125 to be in. I can release 4.1.1 to staging tomorrow morning CET if nobody objects that. Not sure about 4.0.9. We released

[DISCUSS] Drop support for sstable formats m* (in trunk)

If we do not recommend and do not test direct upgrades from 3.x to 5.x, we can clean up a fair bit by removing code related to sstable formats m*, as Cassandra versions 4.x and 5.0 are all on sstable formats n*. We don't allow mixed-version streaming, so it's not possible today to stream any

Re: [DISCUSS] New dependencies with Chronicle-Queue update

On Mon, 13 Mar 2023 at 16:39, Jeremiah D Jordan wrote: > Given we need to upgrade to support JDK17 it seems fine to me. The only > concern I have is that some of those libraries are already pretty old, for > example the most recent jna-platform is 5.13.0 and 5.5.0 is almost 4 years > old. >

Re: Should we cut some new releases?

+1 pon., 13 mar 2023, 20:36 użytkownik Miklosovic, Stefan < stefan.mikloso...@netapp.com> napisał: > Yes, I was waiting for CASSANDRA-18125 to be in. > > I can release 4.1.1 to staging tomorrow morning CET if nobody objects that. > > Not sure about 4.0.9. We released 4.0.8 just few weeks ago. I

Re: [EXTERNAL] Re: [DISCUSS] Next release date

Getting JDK17 far enough to drop JDK8 eta is end of May to June. Blockers to dropping JDK8 are listed against CASSANDRA-18255. Production ready JDK17 support remains a bigger unknown task, which we need more help on. On Mon, 13 Mar 2023 at 8:48, Berenguer Blasi wrote: > TTL (CASSANDRA-14227)

Re: Should we cut some new releases?

Yes, I was waiting for CASSANDRA-18125 to be in. I can release 4.1.1 to staging tomorrow morning CET if nobody objects that. Not sure about 4.0.9. We released 4.0.8 just few weeks ago. I would do 4.1.1 first. From: Ekaterina Dimitrova Sent: Monday,

Re: [DISCUSS] New dependencies with Chronicle-Queue update

Yes exactly. If we are updating a library for some reason, we should update it to the latest one that makes sense.On Mar 13, 2023, at 1:17 PM, Josh McKenzie wrote:I think we should we use the most recent versions of all libraries where possible?”To clarify, are we talking "most recent versions

Re: [DISCUSS] New dependencies with Chronicle-Queue update

> I think we should we use the most recent versions of all libraries where > possible?” To clarify, are we talking "most recent versions of all libraries *when we have to update them anyway for a dependency*"? Not *all libraries all libraries*... If the former, I agree. If the latter, here be

Re: [DISCUSSION] Cassandra + Java 17

Thanks for all of the work on this, Ekaterina! I would add a third point: - If newer JVMs offer a standard way to access things that no longer requires unsafe or native access, we can move to that standard approach once all supported JVMs are in scope The case I was thinking about specifically

Re: [DISCUSSION] Cassandra + Java 17

Hi everyone, To close this thread, I see lazy consensus around JDK internals accesses as follows: - we keep the current accesses to JDK internals in the Cassandra codebase, they were carefully considered during former reviews already. If there is breakage from changes in JDK internals (which are

Re: [DISCUSS] New dependencies with Chronicle-Queue update

“ > Given we need to upgrade to support JDK17 it seems fine to me. The only concern I have is that some of those libraries are already pretty old, for example the most recent jna-platform is 5.13.0 and 5.5.0 is almost 4 years old. I think we should we use the most recent versions of all

Re: Should we cut some new releases?

+1 On Mon, 13 Mar 2023 at 12:23, Benjamin Lerer wrote: > Hi everybody, > > Benedict and Jon recently committed the patch for CASSANDRA-18125 > which fixes some > serious problems at the memtable/flush level. Should we consider cutting >

Should we cut some new releases?

Hi everybody, Benedict and Jon recently committed the patch for CASSANDRA-18125 which fixes some serious problems at the memtable/flush level. Should we consider cutting some releases that contain this fix?

Re: [DISCUSS] New dependencies with Chronicle-Queue update

I know it was just an example but we upgraded JNA to 5.13 in CASSANDRA-18050 as part of the JDK17 effort, so at least that is taken care of. Kind Regards, Brandon On Mon, Mar 13, 2023 at 10:39 AM Jeremiah D Jordan wrote: > > Given we need to upgrade to support JDK17 it seems fine to me. The

Re: [DISCUSS] New dependencies with Chronicle-Queue update

Given we need to upgrade to support JDK17 it seems fine to me. The only concern I have is that some of those libraries are already pretty old, for example the most recent jna-platform is 5.13.0 and 5.5.0 is almost 4 years old. I think we should we use the most recent versions of all libraries

[DISCUSS] Lift MessagingService.minimum_version to 40 in trunk

If we do not recommend and do not test direct upgrades from 3.x to 5.x, we have the opportunity to clean up a fair chunk of code by making `MessagingService.minimum_version=40` As Cassandra versions 4.x and 5.0 are all on `MessagingService.current_version=40` this would mean lifting

Re: [EXTERNAL] Re: [DISCUSS] Next release date

TTL (CASSANDRA-14227) is undergoing review and it's in final stages afaik. A big rebase and perf re-testing will be needed to confirm all is still good. I would expect this to happen this month. Then the feature flag and downgradability issue, which are unkown atm in terms of complexity, are

[DISCUSS] New dependencies with Chronicle-Queue update

JDK17 requires us to update our chronicle-queue dependency: CASSANDRA-18049 We use chronicle-queue for both audit logging and fql. This update pulls in a number of new transitive dependencies. affinity-3.23ea1.jar asm-analysis-9.2.jar asm-commons-9.2.jar asm-tree-9.2.jar asm-util-9.2.jar

Re: [DISCUSS] Remove deprecated CQL functions dateof and unixtimestampof on 5.0

Actually, this one https://issues.apache.org/jira/browse/CASSANDRA-18306 From: Miklosovic, Stefan Sent: Monday, March 13, 2023 13:26 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] Remove deprecated CQL functions dateof and unixtimestampof on 5.0

Re: [DISCUSS] Remove deprecated CQL functions dateof and unixtimestampof on 5.0

I am +1. Could you please link the ticket to https://issues.apache.org/jira/browse/CASSANDRA-17973 ? Thanks From: Andrés de la Peña Sent: Monday, March 13, 2023 13:22 To: dev@cassandra.apache.org Subject: [DISCUSS] Remove deprecated CQL functions

[DISCUSS] Remove deprecated CQL functions dateof and unixtimestampof on 5.0

The CQL functions "dateof" and "unixtimestampof" were deprecated on Cassandra 2.2.0, almost eight years ago [1]. They were deprecated in favour of the then new "totimestamp" and "tounixtimestamp" functions. I think that we can finally remove those functions in 5.0, since they have been deprecated

Re: [EXTERNAL] Re: [DISCUSS] Next release date

CEP-7 Storage Attached Index is in review with ~430 files and ~70k LOC. The bulk of the project is in 3 main patches. The first patch (in-memory index and query path) is merged to the feature branch CASSANDRA-16052 and the second patch (on-disk write and literal / string index) is in review. Mike

Re: [EXTERNAL] Re: [DISCUSS] Next release date

> > Should we clarify that part first by getting an idea of the status of the > different CEPs and other big pieces of work? CEP-20 (dynamic data masking) should hopefully be ready by the end of this month. It's composed by seven small tickets. Five of those tickets are ready, and two are under