Re: [DISCUSS] A point of view on Testing Cassandra
Thanks for starting discussion! Replying to the thread with what I would have left as comments. –– > As yet, we lack empirical evidence to quantify the relative stability or > instability of our project compared to a peer cohort I think it's more important that we set a standard for the project (e.g., fundamental conformance to properties of the database) rather than attempting to measure quality relative to other DBs. That might be a useful measure, but I don't think it's the most important one. With regard to measuring against a common standard in the project, this is roughly what I had in mind when proposing "Release Quality Metrics" on the list in 2018. I still think making progress on something like this is essential toward defining a quantitative bar for release: https://www.mail-archive.com/dev@cassandra.apache.org/msg13154.html > Conversely, the ability to repeatedly and thoroughly validate the correctness > of both new and existing functionality in the system is vital to the speed > with which we can evolve it's form and function. Strongly agreed. > Utopia (and following section) Some nods to great potential refactors to consider post-4.0 here. ^ > We should productize a kubernetes-centric, infra agnostic tool that has the > following available testing paradigms: This would be an excellent set of capabilities to have. > We need to empower our user community to participate in the testing process... I really like this point. I took as a thought experiment "what would feel great to be able to say" if one were to write a product announcement for 4.0 and landed on something like "Users of Apache Cassandra can preflight their 4.0 upgrade by runing $tool to clone, upgrade, and compare their clusters, ensuring that the upgrade will complete smoothly and correctly." > The less friction and less investment we can require from ecosystem > participants, the more we can expect them to engage in desired behavior. +1 –– I like the document and there's a lot that has me nodding. Toward the opening statement on "empirical evidence to quantify relative stability," I'd love to revisit discussion on quantifying attributes like these here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=93324430 – Scott From: David Capwell Sent: Tuesday, July 14, 2020 6:23 PM To: dev@cassandra.apache.org Subject: Re: [DISCUSS] A point of view on Testing Cassandra I am also not fully clear on the motives, but welcome anything which helps bring in better and more robust testing; thanks for starting this. Since I can not comment in the doc I have to copy/paste and put here... =( Reality > ... > investing in improving our smoke and integration testing as much as is > possible with our current constraints seems prudent. This section reads as very anti-adding tests to test/unit; I am 100% in favor of improving/creating our smoke, integration, regression, performance, E2E, etc. testing, but don't think I am as negative to test/unit, these tests are still valuable and more are welcome. To enumerate a punch list of traits we as engineers need from a testing > suite Would be good to speak about portability, accessibility, and version independents. If a new contributor wants to add tests to this suite they need to be able to run it, and it should run within a "reasonable" time frame; one of the big issuers with python dtests is that it takes 14+ hours to run, this makes it no longer accessible to new contributors. On Tue, Jul 14, 2020 at 11:47 AM Joshua McKenzie wrote: > The purpose is purely to signal a point of view on the state of testing in > the codebase, some shortcomings of the architecture, and what a few of us > are doing and further planning to do about it. Kind of a "prompt discussion > if anyone has a wild allergic reaction to it, or encourage collaboration if > they have a wild positive reaction" sort of thing. Maybe a spiritual > "CEP-lite". :) > > I would advocate that we be very selective about the topics on which we > strive for a consistent shared point of view as a project. There are a lot > of us and we all have different experiences and different points of view > that lead to different perspectives and value systems. Agreeing on discrete > definitions of done, 100% - that's table stakes. But agreeing on how we get > there, my personal take is we'd all be well served to spend our energy > Doing the Work and expressing these complementary positions rather than > trying to bend everyone to one consistent point of view. > > Let a thousand flowers bloom, as someone wise recently told me. :) > > That said, this work will be happening in an open source repo with a > permissive license (almost certainly ASLv2), likely using github issues, so > anyone that wants to collaborate on it would be most welcome. I can make > sure Gianluca, Charles, Berenguer, and others bring that to this ML thread > once we've started
Re: [DISCUSS] A point of view on Testing Cassandra
I am also not fully clear on the motives, but welcome anything which helps bring in better and more robust testing; thanks for starting this. Since I can not comment in the doc I have to copy/paste and put here... =( Reality > ... > investing in improving our smoke and integration testing as much as is > possible with our current constraints seems prudent. This section reads as very anti-adding tests to test/unit; I am 100% in favor of improving/creating our smoke, integration, regression, performance, E2E, etc. testing, but don't think I am as negative to test/unit, these tests are still valuable and more are welcome. To enumerate a punch list of traits we as engineers need from a testing > suite Would be good to speak about portability, accessibility, and version independents. If a new contributor wants to add tests to this suite they need to be able to run it, and it should run within a "reasonable" time frame; one of the big issuers with python dtests is that it takes 14+ hours to run, this makes it no longer accessible to new contributors. On Tue, Jul 14, 2020 at 11:47 AM Joshua McKenzie wrote: > The purpose is purely to signal a point of view on the state of testing in > the codebase, some shortcomings of the architecture, and what a few of us > are doing and further planning to do about it. Kind of a "prompt discussion > if anyone has a wild allergic reaction to it, or encourage collaboration if > they have a wild positive reaction" sort of thing. Maybe a spiritual > "CEP-lite". :) > > I would advocate that we be very selective about the topics on which we > strive for a consistent shared point of view as a project. There are a lot > of us and we all have different experiences and different points of view > that lead to different perspectives and value systems. Agreeing on discrete > definitions of done, 100% - that's table stakes. But agreeing on how we get > there, my personal take is we'd all be well served to spend our energy > Doing the Work and expressing these complementary positions rather than > trying to bend everyone to one consistent point of view. > > Let a thousand flowers bloom, as someone wise recently told me. :) > > That said, this work will be happening in an open source repo with a > permissive license (almost certainly ASLv2), likely using github issues, so > anyone that wants to collaborate on it would be most welcome. I can make > sure Gianluca, Charles, Berenguer, and others bring that to this ML thread > once we've started open-sourcing things. > > On Tue, Jul 14, 2020 at 4:25 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > It does raise the bar to critiquing the document though, but perhaps > > that's also a feature. > > > > Perhaps we can first discuss the purpose of the document? It seems to be > a > > mix of mission statement for the project, as well as your own near term > > roadmap? Should we interpret it only as an advertisement of your own > view > > of the problems the project faces, as a start to dialogue, or is the > > purpose to solicit feedback? > > > > Would it be helpful to work towards a similar document the whole > community > > endorses, with a shared mission statement, and a (perhaps loosely > defined) > > shared roadmap? > > > > I'd like to call out some specific things in the document that I am > > personally excited by: the project has long lacked a coherent, repeatable > > approach to performance testing and regressions; combined with easy > > visualisation tools this would be a huge win. The FQL sampling with data > > distribution inference is also something that has been discussed > privately > > elsewhere, and would be hugely advantageous to the former, so that we can > > discover representative workloads. > > > > Thanks for taking the time to put this together, and start this dialogue. > > > > > > On 13/07/2020, 23:41, "Joshua McKenzie" wrote: > > > > > > > > Can you please allow comments on the doc so we can leave feedback. > > > > > > > > > > Doc is view only; figured we could keep this to the ML. > > > > > That's a feature, not a bug. > > > > Happy to chat here or on slack w/anyone. This is a complex topic so > > long-form or high bandwidth communication is a better fit than gdoc > > comments. They rapidly become unwieldy. > > > > On Mon, Jul 13, 2020 at 6:17 PM sankalp kohli < > kohlisank...@gmail.com> > > wrote: > > > > > Can you please allow comments on the doc so we can leave feedback. > > > > > > On Mon, Jul 13, 2020 at 2:16 PM Joshua McKenzie < > > jmcken...@apache.org> > > > wrote: > > > > > > > Link: > > > > > > > > > > > > > > https://docs.google.com/document/d/1ktuBWpD2NLurB9PUvmbwGgrXsgnyU58koOseZAfaFBQ/edit# > > > > > > > > > > > > Myself and a few other contributors are working with this point > of > > view > > > as > > > > our frame of where we're going to work on improving testing on > the > >
Re: [VOTE] Release Apache Cassandra 3.11.7
On Wed, 15 Jul 2020 at 00:57, Jon Haddad wrote: > Just wanted to note - a vote passes if there are 3 binding +1 and no -1's. > > > https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance Well spotted, that is now fixed https://github.com/apache/cassandra-builds/commit/3a23e69bbb40f9fadee706a9306498193a16e77b
[VOTE] Release Apache Cassandra 4.0-beta1
Proposing the test build of Cassandra 4.0-beta1 for release. sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available here: https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/ The vote will be open for 72 hours (longer if needed). Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and no -1s. Eventual publishing and announcement of the 4.0-beta1 release will be coordinated, as described in https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E [1]: CHANGES.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative [2]: NEWS.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative
Re: [VOTE] Release Apache Cassandra 3.11.7
Just wanted to note - a vote passes if there are 3 binding +1 and no -1's. https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance On Tue, Jul 14, 2020 at 3:47 PM Mick Semb Wever wrote: > Proposing the test build of Cassandra 3.11.7 for release. > > sha1: 9fe62b3e40147fda2cc081744bd375b04574aef7 > Git: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.7-tentative > Maven Artifacts: > > https://repository.apache.org/content/repositories/orgapachecassandra-1209/org/apache/cassandra/cassandra-all/3.11.7/ > > The Source and Build Artifacts, and the Debian and RPM packages and > repositories, are available here: > https://dist.apache.org/repos/dist/dev/cassandra/3.11.7/ > > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s. > > [1]: CHANGES.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.7-tentative > [2]: NEWS.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.7-tentative >
[VOTE] Release Apache Cassandra 2.2.17
Proposing the test build of Cassandra 2.2.17 for release. sha1: cd006d275aa9b6e937c6ebd036d4d27c4ed18dbe Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.17-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1207/org/apache/cassandra/cassandra-all/2.2.17/ The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available here: https://dist.apache.org/repos/dist/dev/cassandra/2.2.17/ The vote will be open for 72 hours (longer if needed). Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s. [1]: CHANGES.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.17-tentative [2]: NEWS.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.17-tentative
[VOTE] Release Apache Cassandra 3.0.21
Proposing the test build of Cassandra 3.0.21 for release. sha1: e39d1da325f5853ab3a64d92ecf52f8271239b9e Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.21-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1208/org/apache/cassandra/cassandra-all/3.0.21/ The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available here: https://dist.apache.org/repos/dist/dev/cassandra/3.0.21/ The vote will be open for 72 hours (longer if needed). Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s. [1]: CHANGES.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.21-tentative [2]: NEWS.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.21-tentative
[VOTE] Release Apache Cassandra 3.11.7
Proposing the test build of Cassandra 3.11.7 for release. sha1: 9fe62b3e40147fda2cc081744bd375b04574aef7 Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.7-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1209/org/apache/cassandra/cassandra-all/3.11.7/ The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available here: https://dist.apache.org/repos/dist/dev/cassandra/3.11.7/ The vote will be open for 72 hours (longer if needed). Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s. [1]: CHANGES.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.7-tentative [2]: NEWS.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.7-tentative
Re: [DISCUSS] Revisiting Java 11's experimental status
I think we should start getting automated testing to use java 11 in 4.0, but that stability on 4.0 should not be a blocker for 4.0. Mick is doing a lot of work to get builds running with java 11 (see https://issues.apache.org/jira/browse/CASSANDRA-15809) and a lot more work is needed to get java 11 on-par with java 8 in CI. We also lack a lot of longer running tests in CI, so as the testing epics start getting fleshed out, I hope we can make better use of java 11 earlier rather than adding after. On Tue, Jul 14, 2020 at 9:56 AM Jon Haddad wrote: > My goal here was to collect information, specifically around what people's > needs are and what people are testing. Some teams have a mandate they need > to move to Java 11, Python 3, etc. Some just want to take advantage of > features like low overhead heap profiling [1]. I don't have the visibility > that I used to at TLP, but I do remember there were quite a few teams out > there looking to move to JDK 11. > > My original email didn't take a position on whether or not we should remove > the experimental flag, I don't know if we should. I'm trying to figure it > out. If we do, then there's some issues we have to address, like our CI as > Josh pointed out. > > As a user, if I were to download a brand new release of some software that > didn't support the latest stable JDK 2 years after it was released, I'd be > a bit worried, and I think it would reflect poorly on the project. > > Anyways, the TL;DR is that if people are doing large scale testing of 4.0 > with Java 11 with the intent of putting it in production (See Jon > Meredith's email), then it's a matter of determining what bar we need to > cross in order to say JDK 11 support isn't experimental anymore. > > [1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8171119 > > > On Tue, Jul 14, 2020 at 6:02 AM Jeff Jirsa wrote: > > > Zgc > > > > > On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote: > > > > > > > > >> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: > > >> > > >> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even > > prod ready in jdk11 , so what’s the motivation and what does the project > > gain from revisiting the experimental designation on jdk11? > > > > > > Can you elaborate on what’s not even prod ready in Java 11? > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: [DISCUSS] A point of view on Testing Cassandra
The purpose is purely to signal a point of view on the state of testing in the codebase, some shortcomings of the architecture, and what a few of us are doing and further planning to do about it. Kind of a "prompt discussion if anyone has a wild allergic reaction to it, or encourage collaboration if they have a wild positive reaction" sort of thing. Maybe a spiritual "CEP-lite". :) I would advocate that we be very selective about the topics on which we strive for a consistent shared point of view as a project. There are a lot of us and we all have different experiences and different points of view that lead to different perspectives and value systems. Agreeing on discrete definitions of done, 100% - that's table stakes. But agreeing on how we get there, my personal take is we'd all be well served to spend our energy Doing the Work and expressing these complementary positions rather than trying to bend everyone to one consistent point of view. Let a thousand flowers bloom, as someone wise recently told me. :) That said, this work will be happening in an open source repo with a permissive license (almost certainly ASLv2), likely using github issues, so anyone that wants to collaborate on it would be most welcome. I can make sure Gianluca, Charles, Berenguer, and others bring that to this ML thread once we've started open-sourcing things. On Tue, Jul 14, 2020 at 4:25 AM Benedict Elliott Smith wrote: > It does raise the bar to critiquing the document though, but perhaps > that's also a feature. > > Perhaps we can first discuss the purpose of the document? It seems to be a > mix of mission statement for the project, as well as your own near term > roadmap? Should we interpret it only as an advertisement of your own view > of the problems the project faces, as a start to dialogue, or is the > purpose to solicit feedback? > > Would it be helpful to work towards a similar document the whole community > endorses, with a shared mission statement, and a (perhaps loosely defined) > shared roadmap? > > I'd like to call out some specific things in the document that I am > personally excited by: the project has long lacked a coherent, repeatable > approach to performance testing and regressions; combined with easy > visualisation tools this would be a huge win. The FQL sampling with data > distribution inference is also something that has been discussed privately > elsewhere, and would be hugely advantageous to the former, so that we can > discover representative workloads. > > Thanks for taking the time to put this together, and start this dialogue. > > > On 13/07/2020, 23:41, "Joshua McKenzie" wrote: > > > > > Can you please allow comments on the doc so we can leave feedback. > > > > > > Doc is view only; figured we could keep this to the ML. > > > That's a feature, not a bug. > > Happy to chat here or on slack w/anyone. This is a complex topic so > long-form or high bandwidth communication is a better fit than gdoc > comments. They rapidly become unwieldy. > > On Mon, Jul 13, 2020 at 6:17 PM sankalp kohli > wrote: > > > Can you please allow comments on the doc so we can leave feedback. > > > > On Mon, Jul 13, 2020 at 2:16 PM Joshua McKenzie < > jmcken...@apache.org> > > wrote: > > > > > Link: > > > > > > > > > https://docs.google.com/document/d/1ktuBWpD2NLurB9PUvmbwGgrXsgnyU58koOseZAfaFBQ/edit# > > > > > > > > > Myself and a few other contributors are working with this point of > view > > as > > > our frame of where we're going to work on improving testing on the > > project. > > > I figured it might be useful to foster collaboration more broadly > in the > > > community as well as provide people with the opportunity to > discuss work > > > they're doing they may not yet have had a chance to bring up or > open > > > source. While fallout is already open-sourced, expect the schema > > anonymizer > > > and some of the cassandra-diff + nosqlbench framework effort to be > > > open-sourced / openly worked on soon. Anyone that's interested in > > > collaborating, that would be highly welcome. > > > > > > Doc is view only; figured we could keep this to the ML. > > > > > > Thanks. > > > > > > ~Josh > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] Revisiting Java 11's experimental status
My goal here was to collect information, specifically around what people's needs are and what people are testing. Some teams have a mandate they need to move to Java 11, Python 3, etc. Some just want to take advantage of features like low overhead heap profiling [1]. I don't have the visibility that I used to at TLP, but I do remember there were quite a few teams out there looking to move to JDK 11. My original email didn't take a position on whether or not we should remove the experimental flag, I don't know if we should. I'm trying to figure it out. If we do, then there's some issues we have to address, like our CI as Josh pointed out. As a user, if I were to download a brand new release of some software that didn't support the latest stable JDK 2 years after it was released, I'd be a bit worried, and I think it would reflect poorly on the project. Anyways, the TL;DR is that if people are doing large scale testing of 4.0 with Java 11 with the intent of putting it in production (See Jon Meredith's email), then it's a matter of determining what bar we need to cross in order to say JDK 11 support isn't experimental anymore. [1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8171119 On Tue, Jul 14, 2020 at 6:02 AM Jeff Jirsa wrote: > Zgc > > > On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote: > > > > > >> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: > >> > >> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even > prod ready in jdk11 , so what’s the motivation and what does the project > gain from revisiting the experimental designation on jdk11? > > > > Can you elaborate on what’s not even prod ready in Java 11? > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] Revisiting Java 11's experimental status
Zgc > On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote: > > >> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: >> >> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even prod >> ready in jdk11 , so what’s the motivation and what does the project gain >> from revisiting the experimental designation on jdk11? > > Can you elaborate on what’s not even prod ready in Java 11? - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Revisiting Java 11's experimental status
If I understand correctly, you’re proposing to “officially support” Java 8 and 11 (i.e. remove the “experimental” tag for Java 11). +1 on that from my side. It totally makes sense to me for 4.0. Don’t want to hijack the original thread (as it’s just about C* 4.0), but some thoughts about post-4.0: Java 8 gets (probably just critical) patches until 2026 (e.g. from adoptopenjdk, not sure about other vendors). But I suspect 2026 is really the very last date until 8 finally gets retired. Considering that users still run C* 2.1 (released 2014) and older, it’s probably reasonable to plan to remove Java 8-support in the next version (i.e. 4.1) and require the last LTS Java (11, 17, etc) _and_ the current non-LTS (on a best-effort/experimental basis). Especially the “new GCs” (Z, Shenandoah) and a bunch of other upcoming features (e.g. Loom, Panama, Records) are very interesting and beneficial for the project. I did some experiments and a recent build works against Java 14 (and a nightly build of 15 IIRC). A couple of unit tests need to be adopted (fix the no longer working java.lang.ref.Field code in some unit tests) and Nashorn needs to be replaced (it has recently been removed). It is not that much work, it just needs to be done. — Robert Stupp @snazy > On 13. Jul 2020, at 20:42, Jon Haddad wrote: > > Support for Java 11 was added a long time ago, and it's been about 2 years > since it was released (Sept 2018). Had we released Cassandra 4 close to > that date, I'd be fine with keeping the status as experimental, but at this > point I'm wondering if releasing a new major version of C* that's primarily > targeting Java 8 as the only "official" supported version is a good idea. > > To those of you that are planning on rolling out C* 4.0, are you planning > on using Java 8 still, or moving to 11? Speaking for myself, I can say I > don't think I'd want to use 8 anymore. If most folks are testing with 11 > at this point, I think we should consider making 11 the recommended version > and really only encouraging Java 8 for legacy purposes - teams who have a > restriction that prevents them from upgrading. > > To those of you planning on moving to 4.0 soon after it's release, are you > planning on deploying to JDK 11 or 8? > > [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
Re: [DISCUSS] Revisiting Java 11's experimental status
> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: > > Perhaps the most notable parts of jdk11 (for cassandra) aren’t even prod > ready in jdk11 , so what’s the motivation and what does the project gain from > revisiting the experimental designation on jdk11? Can you elaborate on what’s not even prod ready in Java 11?
