Correct me if I am wrong, but I see the following consensus so far, on the proposal.
C* 2.2 AnimalSniffer Use AnimalSniffer for compile-time feedback on JDK 1.7 compatibility - complete consensus so far Circle CI Builds In addition to existing JDK 1.8 support, build against JDK 1.7, and [optionally] run unit tests and DTests against JDK 1.7 - Dinesh and Sumanth +1 so far. Mick - I am not sure if you are +0 or -1 on this. C* 4.0 Circle CI Builds In addition to existing JDK 1.8 support, build against JDK 11 and [optionally] run unit tests and DTests against JDK 11. - complete consensus so far If anyone has any further feedback, please comment. Thanks, Sumanth On Fri, Aug 24, 2018 at 7:27 AM Sumanth Pasupuleti <spasupul...@netflix.com.invalid> wrote: > > I'm still a bit confused as to what's the benefit in compiling with > jdk1.7 and then testing with jdk1.7 or jdk1.8 > I meant two separate workflows for each JDK i.e. > Workflow1: Build against jdk1.7, and optionally run UTs and Dtests against > 1.7 > Workflow2: Build against jdk1.8, and run UTs and DTests against 1.8. > > > If you find breakages here that otherwise don't exist when it's compiled > with jdk1.8 then that's just false-positives. As well as generally wasting > CI resources. > If we find breakages in workflow1, and not in workflow 2, how would they be > false positives? we will need to then look into whats causing breakages > with 1.7, isn't it? > > Thanks, > Sumanth > > On Thu, Aug 23, 2018 at 7:59 PM, Mick Semb Wever <m...@apache.org> wrote: > > > > However, in addition to using such a > > > tool, I believe, when we make a release, we should build against the > > actual > > > JDKs we support (that way, we are not making a release just based on > the > > > result of an external tool), and we should be able to optionally run > UTs > > > and DTests against the JDK (i.e. Java7 and Java8 for C* 2.2). > > > > > > I'm still a bit confused as to what's the benefit in compiling with > jdk1.7 > > and then testing with jdk1.7 or jdk1.8 > > > > If you find breakages here that otherwise don't exist when it's compiled > > with jdk1.8 then that's just false-positives. As well as generally > wasting > > CI resources. > > > > Either way, there's not much point discussing this as Cassandra-2.1 is > > about EOL, and Cassandra-4.0 is stuck with a very specific compile. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
