+1 from me on both points below -- Jeff Jirsa
> On Aug 28, 2018, at 1:40 PM, Sumanth Pasupuleti > <sumanth.pasupuleti...@gmail.com> wrote: > > 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 >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
