I really don't see any benefit at all in having any additional Java 1.7 specific build and testing changes for the 2.2 branch. The 2.2 version is reaching EOL and will only get critical patches until then anyways. I also can't remember any reports on regressions in 2.2 bug fix releases specific to 1.7. So what's the actual problem we want to solve here?
As for 4.0, we're going to ship multi-release jars, which are targeted against Java 8, but also contain Java 11 classes that will only be used when executed under Java 11 (also currently just a single class). I can see two issues that need our attention with that: * We should make sure to use the "_build_multi_java" target for our CI jobs, so we're really testing the same build that we would ship. It's probably not going to make a real difference, but who knows.. * It would also be nice to have the option to run tests on CI under Java 11, although we only provide "experimental" support for that Java version. Nice to have at this point, as there will be plenty of bugs in 4.0 to fix, until we should spend time looking more closely for more subtle Java 11 issues. But if someone wants to contribute any work to make this happen, I'd be glad to have that option running tests on Java 11, so don't get me wrong. On 07.09.18 04:10, Sumanth Pasupuleti wrote: >> And I would suggest to go further and crash the build with JDK1.7 so we > can take away the possibility for users to shoot their foot off this way. > > I like this suggestion. Either we should be on the side of NO support to > JDK 1.7, or if we say we support JDK1.7, I believe we should be building > against JDK1.7 to make sure we are compliant. > I have a quick clarifying question here - I believe origin of > CASSANDRA-14563 is from the introduction of an API in 2.2 that is > incompatible with 1.7, that has then been manually detected and fixed. Are > you suggesting, going further, we would not support 1.7? > >> Currently I'm unclear on how we would make a stable release using only > JDK8, maybe their are plans on the table i don't know about? > > From the current state of build.xml and from the past discussions, I do > believe as well, that we need both JDKs to make a 4.0 release using > ‘_build_multi_java’. Bonus would be that, the release would also be able to > run against Java11, but that would be an experimental release. > >> I'm not familiar with optional jobs or workflows in CircleCi, do you have > an example of what you mean at hand? > > By optional, I was referring to having workflow definitions in place, but > calls to those workflows commented out. Basically similar to what we have > today. > workflows: > version: 2 > build_and_run_tests: *default_jobs > #build_and_run_tests: *with_dtest_jobs_only > #build_and_run_tests_java11: *with_dtest_jobs_java11 > Jason created CASSANDRA-14609 for this purpose I believe. > >> Off-topic, but what are your thoughts on this? Can we add `ant > artifacts`, and the building of the docs, as a separate jobs into the > existing default CircleCI workflow? I think we should also be looking into > getting https://cassandra.apache.org/doc/latest/ automatically updated > after each successful trunk build, and have > https://cassandra.apache.org/doc/X.Y versions on the docs in place (which > are only updated after each patch release). > > I like all these ideas! I believe we should be able to add a workflow to > test out artifact generation. Will create a JIRA for this. Your suggestions > around auto-update of docs provides a way to keep our website docs > up-to-date. Not sure what it takes to do it though. Will be happy to > explore (as part of separate JIRAs). > > Thanks, > Sumanth > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
