Re: Python and Go callouts during ant compile/build task

Does this also apply to gradle, which now gets downloaded and installed, and is the most recent addition ? The python requirement from gen-doc has been around for over three years now. I agree with the rationale that `ant` should default to `ant check`, keeping newcomers in mind while being more

Re: Python and Go callouts during ant compile/build task

I didn’t say we should disable checks. I thought this was a purpose of CI : to check everything: there’s likely more to break semantically anyways, also harder to detect and fix. I’m also not proposing removing something that was long in place, these dependencies were introduced very recently.

Re: [VOTE] Simplifying our release versioning process

I propose we:- Exclude JDK support from the subject of this vote.- And start a separate [DISCUSS] and [VOTE] thread to cover JDK/JRE lifecycle.Josh’s proposal that we are voting on does not address JDK versioning, and I don’t interpret the text of the proposal as a referendum on it. Many / most did

Re: [VOTE] Simplifying our release versioning process

Isn't the JDK we build with when publishing to maven somewhat of a public interface due to cassandra-all library usage? I agree that we probably just need to clearly document what JVMs we test a release on which is a good signal for what we think will work at runtime (and this may be a much newer J

Re: Python and Go callouts during ant compile/build task

> If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true` I do not think developers have to be forced skip it. Such checks can be a part of CI or merge, but not a common development workflow. It should be in a separate task, and simply calling `ant` should most certainly not i

Re: [VOTE] Simplifying our release versioning process

Pragmatically, I believe our in-jvm upgrade dtests require the 2 versions of C* you're testing to both support running on (and probably right now building on) a shared JDK version. So for instance, if we had: - Release 21.0.0: JDK30, JDK31 - Release 22.0.0: JDK35, JDK40 We wouldn't be able to t

Re: [VOTE] Simplifying our release versioning process

> Also, I thought we had separate discussion about them - that we want to keep > up possibly with the last two LTS versions. This is what I remember as well. 6.0 would support 17/21 as thats the latest, if 7.0 is out before 25, then 7.0 would be 17/21, else it would be 21/25 > On Apr 23, 2025,

Re: [VOTE] Simplifying our release versioning process

> The JVM version also isn’t a feature to deprecate, technically. I agree with this. I think the JVM version the server runs under and how we cycle those is a separate discussion from feature deprecation. There can and has been some overlap there that would need to be handled on a case by case ba

Re: [VOTE] Simplifying our release versioning process

I should say that I also haven’t thought of JDK versions when I voted here. Also, I thought we had separate discussion about them - that we want to keep up possibly with the last two LTS versions. Currently we do not have vision on when will be the next release date, so I cannot personally align JD

Re: Python and Go callouts during ant compile/build task

I think the default build should be to build and check everything. I think that if someone is new it is better to have everything built and checked by default to flag issues. If someone knows what they are doing and wants to speed up the process it is very easy to add the right settings to the an

Re: [VOTE] Simplifying our release versioning process

I agree with Jon that I’m now a bit confused on part of what I voted for. It feels like there is more discussion to be had here. Or we need to split it into two votes if we want to make progress on the part where there is consensus and revisit where there is not. Regarding JVM version what I’ve mo

Re: Python and Go callouts during ant compile/build task

Should we consider making that the default and then passing false explicitly in CI/builds? I agree with Alex it’s a bit surprising and shorter build times when developing would be helpful. Jordan On Wed, Apr 23, 2025 at 13:37 Mick Semb Wever wrote: > Python and Go are used by the gen-doc target

Re: [UPDATE] CEP-37

The long awaited feature of managed repairs is finally happening, this is awesome! :) Congrats all for this achievement! On Wed, Apr 23, 2025 at 4:27 PM Jordan West wrote: > Great work all! Another awesome milestone and huge step forward for the > project! > > On Wed, Apr 23, 2025 at 12:47 Jayd

Re: [VOTE] Simplifying our release versioning process

> If 5.0 supports 17, then 7.0 should too, if we are to say we support 5.0 to 7.0 upgrades. I have to disagree with this. I don't see a good reason have a tight coupling of JVM versions to C* versions, and I also don't see a good reason to overlap outside of CI. Even on CI, the reasoning is a

Re: Python and Go callouts during ant compile/build task

Python and Go are used by the gen-doc target. Code changes can break these, hence it is part of `ant check`. It is not called by `ant jar` If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true` On Wed, 23 Apr 2025 at 22:06, Alex Petrov wrote: > Hi folks, > > Building Cas

Re: [UPDATE] CEP-37

Great work all! Another awesome milestone and huge step forward for the project! On Wed, Apr 23, 2025 at 12:47 Jaydeep Chovatia wrote: > The CEP-37 work has been successfully merged into the trunk today! Please > let me know if you have any issues. > > This merge is a massive win for Apache Cass

Python and Go callouts during ant compile/build task

Hi folks, Building Cassandra jar has been getting increasingly slow, and now it looks like we depend not only on python3 (which was already not optimal), but also on go: ant -Dno-checkstyle=true ... [exec] python3 ./scripts/gen-nodetool-docs.py [exec] python3 ./scripts/convert_y

Re: [VOTE] Simplifying our release versioning process

. > > This reads to me that Java 17 would need to be deprecated now, continue to > be deprecated in 6.0 (at least one major in deprecated), then removed in > 7.0. > This is technically true. But I don't think we need to be explicitly deprecating jdk versions. Users are generally aware of J

Re: [UPDATE] CEP-37

The CEP-37 work has been successfully merged into the trunk today! Please let me know if you have any issues. This merge is a massive win for Apache Cassandra — a significant step forward. But we're not stopping here. There's more to come, and we are committed to pushing repair automation even fur

Re: [VOTE] Simplifying our release versioning process

Have it for *at least* 1 MAJOR in deprecated status (deprecate-then-remove) This reads to me that Java 17 would need to be deprecated now, continue to be deprecated in 6.0 (at least one major in deprecated), then removed in 7.0. On Wed, Apr 23, 2025 at 10:54 AM Ekaterina Dimitrova wrote: > I

Re: [VOTE] Simplifying our release versioning process

I think there is no reason to deprecate 17 in 5.0? I’d think we would deprecate at some point 11 in 5.0, (once the community is confident in 17 being prod ready.) We commit 21 in 6.0 with the plan to remove 11 and switch to 17 builds in 6.0. Any other thoughts? Points of view? On Wed, 23 Apr 202

Re: [VOTE] Simplifying our release versioning process

So to be clear - are we simultaneously calling Java 17 in 5.0 deprecated AND experimental? On Wed, Apr 23, 2025 at 10:23 AM Joseph Lynch wrote: > +1 given "Have it for *at least* 1 MAJOR in deprecated status > (deprecate-then-remove)" > > How does that sit with you Joey? >> > Great! Really app

Re: [VOTE] Simplifying our release versioning process

+1 given "Have it for *at least* 1 MAJOR in deprecated status (deprecate-then-remove)" How does that sit with you Joey? > Great! Really appreciate the clarification! -Joey

Re: [VOTE] Simplifying our release versioning process

> Can we just remove the parenthetical in #4 or clarify that breaking changes > require a minimum duration as determined by a DISCUSS thread - not to be > shorter than 1 major release? The text we're voting on right now leaves us flexible on: 1. What we decide to "API Break" 2. How we decide to

Re: [VOTE] Simplifying our release versioning process

+1 > On Apr 22, 2025, at 7:20 PM, Joseph Lynch wrote: > > I'm unclear if Josh/Ekaterina/Benedict's statements are part of the vote > amending our project governance. If consensus is required for breaking > changes with a strong preference for not breaking I am +1, but the original > text of J

Re: Slack channel - invitation

I've sent you an invitation. Kind Regards, Brandon On Wed, Apr 23, 2025 at 6:59 AM SteuerJ wrote: > > Hi all, > > please can you invite me to the Slack Cassandra channel (I do not have > @apache.org email, I prefer access via steuer.j...@gmail.com). > > Many thanks > > J. Steuer

Re: A Roadmap to Cassandra Analytics 1.0

That’s great - thanks Štefan - please feel free to reach out in slack or via email if you’ve got any questions. Doug > On Apr 23, 2025, at 2:04 AM, Štefan Miklošovič wrote: > > Hi Doug, > > I would love to help you with some of that. Spark 4.0 support seems appealing > to me. Let me check wi

Re: A Roadmap to Cassandra Analytics 1.0

I put everything into Jira directly - there are two epics, one for the “Analytics 1.0 ” release and one for “Cassandra 5.0 support. ”, figuring that once we started work on these thin

Re: Slack channel - invitation

Many thanks, regards Jiri st 23. 4. 2025 v 14:00 odesílatel Brandon Williams napsal: > I've sent you an invitation. > > Kind Regards, > Brandon > > On Wed, Apr 23, 2025 at 6:59 AM SteuerJ wrote: > > > > Hi all, > > > > please can you invite me to the Slack Cassandra channel (I do not have @

Slack channel - invitation

Hi all, please can you invite me to the Slack Cassandra channel (I do not have @ apache.org email, I prefer access via *steuer.j...@gmail.com *). Many thanks J. Steuer