git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supporting multiple JDKs


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
<spasupuleti@xxxxxxxxxxx.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 <mck@xxxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >
> >
>