> > java 11 is experimental, so lets ignore issue X s/ignore/defer until after 4.0 GA/g (semantic difference that may not sway you)
If we block the release on JDK11 issues we find, it *seems* to me that that's the same as saying "JDK11 is supported" assuming we have the same a) level of testing and b) stance on found defects for JDK8 as we have for JDK11. Which I'm totally fine with fwiw. What in my mental model here ^ doesn't match yours? :) Seems there's some gap. On Wed, Aug 19, 2020 at 1:15 PM David Capwell <dcapw...@gmail.com> wrote: > My statement was more coming from the fact that if we test on java 8 and > find an issue it is a release blocker, so saying java 11 should be treated > with the same regard as java 8 when it comes to filing/fixing issues; when > it comes to filing and fixing issues, we shouldn't have different stances > on different JVMs. I don't want us to say "java 11 is experimental, so > lets ignore issue X", we will have a hard time getting out of > experimental if we have this stance. > > Now, don't get me wrong. If something is very specific to java 11 and we > can reason that the impact to users is near zero, I am fine not marking the > issue as a release blocker. An example is that jvm dtests crash the JVM > because of a race condition with CMS and class unloading, this issue > shouldn't block the release but we should still find a way to make it > stable (changed flags when running tests on java 11 to avoid the issue). > > With regard to #2, we have a ways to go to get CI on-par but there is > traction already on both fronts. I run the java (not python) suite on java > 11 frequently and see that known flaky tests are still flaky on java 11, > though the suite tends to pass with enough retries. > > > On Wed, Aug 19, 2020 at 9:51 AM Joshua McKenzie <jmcken...@apache.org> > wrote: > > > > > > > 3) during 4.0 qualification, issues found on jdk 11 should block the > > > release > > > > Maybe we let 2 run and see how many issues there are before we call > release > > blocking? > > > > > > > > On Tue, Aug 18, 2020 at 10:05 PM David Capwell <dcapw...@gmail.com> > wrote: > > > > > I would propose the following: > > > > > > 1) leave jdk 11 marked as experimental > > > 2) make sure CI runs jdk 8 and jdk 11 for all builds (circle / jenkins) > > > 3) during 4.0 qualification, issues found on jdk 11 should block the > > > release > > > > > > This should get us in good shape to potentially be ready to flip the > > switch > > > in 4.1 or even 4.0.1; given that not everyone is signing up to test > java > > > 11, #3 might not be enough to fully mark stable. > > > > > > On Tue, Aug 18, 2020 at 6:10 PM Joshua McKenzie <jmcken...@apache.org> > > > wrote: > > > > > > > Where did we land on this? Don't seem to have a clear consensus from > > > thread > > > > discussion. > > > > > > > > On Mon, Jul 20, 2020 at 10:02 PM Deepak Vohra > > <dvohr...@yahoo.com.invalid > > > > > > > > wrote: > > > > > > > > > The same link was posted earlier also. > > > > > For Java 8 and 11 the poll result is very similar. > > > > > Java 8 =58.4%Java 11 =22.56% > > > > > > > > > > > > > > > On Monday, July 20, 2020, 04:38:03 p.m. PDT, Joshua McKenzie < > > > > > jmcken...@apache.org> wrote: > > > > > > > > > > That's remarkably close to the jrebel results for 2020: > > > > > > > > > > > https://www.jrebel.com/blog/2020-java-technology-report#java-version > > > > > > > > > > Came across this this past weekend doing unrelated research; can't > > > vouch > > > > > for the accuracy / methods / etc. > > > > > > > > > > > > > > > On Mon, Jul 20, 2020 at 7:32 PM Jeff Jirsa <jji...@gmail.com> > wrote: > > > > > > > > > > > Got it, thanks for the correction. > > > > > > > > > > > > > > > > > > On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams < > dri...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > I believe you can run them on 11, but you can't build them on > it. > > > > > > > > > > > > > > On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa <jji...@gmail.com> > > > wrote: > > > > > > > > > > > > > > > > I still dont get it, because you can't use any released > version > > > of > > > > > > > > cassandra with anything other than jdk8. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin < > > > > pmcfa...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > Follow-up on the informal poll I did on twitter: > > > > > > > > > > > > > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21 > > > > > > > > > > > > > > > > > > Offered up as data to be used as you will. > > > > > > > > > > > > > > > > > > 161 votes > > > > > > > > > <= JDK8: 59% > > > > > > > > > JDK9 or 10: 7% > > > > > > > > > JDK11 or 12: 27% > > > > > > > > > JDK13 or 14: 7% > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp < > sn...@snazy.de > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Yea, ZGC is kinda tricky in 11. > > > > > > > > > > > > > > > > > > > > — > > > > > > > > > > Robert Stupp > > > > > > > > > > @snazy > > > > > > > > > > > > > > > > > > > > > On 14. Jul 2020, at 15:02, Jeff Jirsa < > jji...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Zgc > > > > > > > > > > > > > > > > > > > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp < > > sn...@snazy.de > > > > > > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa < > > jji...@gmail.com> > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
