> 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 > >
