Re: [DISCUSS] restrict JDK test matrix

[Alessandro Solimando]

Hello everyone,
I have prepared a PR, if anyone feels like taking a look at it, it's here:
https://github.com/apache/calcite/pull/2928

If there are no feedback/objections I will merge it early next week.

Thanks again for sharing your thoughts around this!

Best regards,
Alessandro

On Tue, 4 Oct 2022 at 12:04, Alessandro Solimando <
alessandro.solima...@gmail.com> wrote:

> Julian, Stamatis,
> thanks for your input!
>
> Since it seems that there is consensus around the topic, I have logged
> CALCITE-5306 .
>
> As soon as I have a PR ready, I will reply to this thread too, in order to
> collect opinions and feedback.
>
> Best regards,
> Alessandro
>
> On Tue, 4 Oct 2022 at 11:12, Stamatis Zampetakis 
> wrote:
>
>> Hello,
>>
>> It is not recommended to use EOL software so dropping those JDK versions
>> from the test matrix makes sense. Anyways it wouldn't be surprising if
>> Jenkins, Travis, Github Actions, etc., remove those EOL versions as well
>> at
>> some point.
>>
>> Best,
>> Stamatis
>>
>> On Mon, Oct 3, 2022 at 3:15 PM Julian Hyde 
>> wrote:
>>
>> > It makes sense to only test on 8, 11, 17 and the latest. Testing on
>> other
>> > versions is going to waste time checking on false negatives. I don’t
>> > remember whether there’s ever been an issue on, say, 15, that wasn’t
>> also
>> > present in 11 or 17.
>> >
>> > Maybe it’s a distinction without a difference, but I think we should
>> still
>> > support the full range of JDK versions.  If I submit a change that
>> breaks
>> > the build on JDK 13, you should tell me and I should fix it. I don’t use
>> > sdkman and can create a JDK 13 environment easily enough from the JDK’s
>> > binary tarball.
>> >
>> > Julian
>> >
>> > > On Oct 3, 2022, at 5:38 AM, Alessandro Solimando <
>> > alessandro.solima...@gmail.com> wrote:
>> > >
>> > > Hello everyone,
>> > > I was checking a build failure
>> > > 
>> > related to
>> > > JDK15 and I wanted to try it locally, however I can't do it via sdkman
>> > >  (a "multi-platform software manager") as JDK is
>> not
>> > > anymore available. This is not the first time, and it makes review
>> tasks
>> > > complicated sometimes (in this specific case it seems an ENV issue,
>> but
>> > > that's not the point here).
>> > >
>> > > I wanted to discuss with you if we really want to keep those "recent
>> but
>> > > EOL" versions or not in our test matrix.
>> > >
>> > > I know that JDK8 is EOL too, but lots of projects are still based on
>> it
>> > and
>> > > it's sadly running in PROD in many places for the same reason. In my
>> > (maybe
>> > > limited) experience, those who upgraded to newer versions (> 11),
>> aren't
>> > > likely to get stuck at, say, 15 and can't move to 17. Is my assumption
>> > > correct in your experience?
>> > >
>> > > In my sdkman on MacOS I only see JDK 8, 11, 17, 20, 21, 22, and I
>> > strongly
>> > > suspect they are following some criteria based on LTS/EOL versions.
>> > >
>> > > Shall we try to do something similar for Calcite and remove
>> non-LTS+EOL
>> > > versions higher than 11?
>> > >
>> > > Best regards,
>> > > Alessandro
>> >
>>
>

Re: [DISCUSS] restrict JDK test matrix

[Alessandro Solimando]

Julian, Stamatis,
thanks for your input!

Since it seems that there is consensus around the topic, I have logged
CALCITE-5306 .

As soon as I have a PR ready, I will reply to this thread too, in order to
collect opinions and feedback.

Best regards,
Alessandro

On Tue, 4 Oct 2022 at 11:12, Stamatis Zampetakis  wrote:

> Hello,
>
> It is not recommended to use EOL software so dropping those JDK versions
> from the test matrix makes sense. Anyways it wouldn't be surprising if
> Jenkins, Travis, Github Actions, etc., remove those EOL versions as well at
> some point.
>
> Best,
> Stamatis
>
> On Mon, Oct 3, 2022 at 3:15 PM Julian Hyde  wrote:
>
> > It makes sense to only test on 8, 11, 17 and the latest. Testing on other
> > versions is going to waste time checking on false negatives. I don’t
> > remember whether there’s ever been an issue on, say, 15, that wasn’t also
> > present in 11 or 17.
> >
> > Maybe it’s a distinction without a difference, but I think we should
> still
> > support the full range of JDK versions.  If I submit a change that breaks
> > the build on JDK 13, you should tell me and I should fix it. I don’t use
> > sdkman and can create a JDK 13 environment easily enough from the JDK’s
> > binary tarball.
> >
> > Julian
> >
> > > On Oct 3, 2022, at 5:38 AM, Alessandro Solimando <
> > alessandro.solima...@gmail.com> wrote:
> > >
> > > Hello everyone,
> > > I was checking a build failure
> > > 
> > related to
> > > JDK15 and I wanted to try it locally, however I can't do it via sdkman
> > >  (a "multi-platform software manager") as JDK is
> not
> > > anymore available. This is not the first time, and it makes review
> tasks
> > > complicated sometimes (in this specific case it seems an ENV issue, but
> > > that's not the point here).
> > >
> > > I wanted to discuss with you if we really want to keep those "recent
> but
> > > EOL" versions or not in our test matrix.
> > >
> > > I know that JDK8 is EOL too, but lots of projects are still based on it
> > and
> > > it's sadly running in PROD in many places for the same reason. In my
> > (maybe
> > > limited) experience, those who upgraded to newer versions (> 11),
> aren't
> > > likely to get stuck at, say, 15 and can't move to 17. Is my assumption
> > > correct in your experience?
> > >
> > > In my sdkman on MacOS I only see JDK 8, 11, 17, 20, 21, 22, and I
> > strongly
> > > suspect they are following some criteria based on LTS/EOL versions.
> > >
> > > Shall we try to do something similar for Calcite and remove non-LTS+EOL
> > > versions higher than 11?
> > >
> > > Best regards,
> > > Alessandro
> >
>

Re: [DISCUSS] restrict JDK test matrix

[Stamatis Zampetakis]

Hello,

It is not recommended to use EOL software so dropping those JDK versions
from the test matrix makes sense. Anyways it wouldn't be surprising if
Jenkins, Travis, Github Actions, etc., remove those EOL versions as well at
some point.

Best,
Stamatis

On Mon, Oct 3, 2022 at 3:15 PM Julian Hyde  wrote:

> It makes sense to only test on 8, 11, 17 and the latest. Testing on other
> versions is going to waste time checking on false negatives. I don’t
> remember whether there’s ever been an issue on, say, 15, that wasn’t also
> present in 11 or 17.
>
> Maybe it’s a distinction without a difference, but I think we should still
> support the full range of JDK versions.  If I submit a change that breaks
> the build on JDK 13, you should tell me and I should fix it. I don’t use
> sdkman and can create a JDK 13 environment easily enough from the JDK’s
> binary tarball.
>
> Julian
>
> > On Oct 3, 2022, at 5:38 AM, Alessandro Solimando <
> alessandro.solima...@gmail.com> wrote:
> >
> > Hello everyone,
> > I was checking a build failure
> > 
> related to
> > JDK15 and I wanted to try it locally, however I can't do it via sdkman
> >  (a "multi-platform software manager") as JDK is not
> > anymore available. This is not the first time, and it makes review tasks
> > complicated sometimes (in this specific case it seems an ENV issue, but
> > that's not the point here).
> >
> > I wanted to discuss with you if we really want to keep those "recent but
> > EOL" versions or not in our test matrix.
> >
> > I know that JDK8 is EOL too, but lots of projects are still based on it
> and
> > it's sadly running in PROD in many places for the same reason. In my
> (maybe
> > limited) experience, those who upgraded to newer versions (> 11), aren't
> > likely to get stuck at, say, 15 and can't move to 17. Is my assumption
> > correct in your experience?
> >
> > In my sdkman on MacOS I only see JDK 8, 11, 17, 20, 21, 22, and I
> strongly
> > suspect they are following some criteria based on LTS/EOL versions.
> >
> > Shall we try to do something similar for Calcite and remove non-LTS+EOL
> > versions higher than 11?
> >
> > Best regards,
> > Alessandro
>

Re: [DISCUSS] restrict JDK test matrix

[Julian Hyde]

It makes sense to only test on 8, 11, 17 and the latest. Testing on other 
versions is going to waste time checking on false negatives. I don’t remember 
whether there’s ever been an issue on, say, 15, that wasn’t also present in 11 
or 17. 

Maybe it’s a distinction without a difference, but I think we should still 
support the full range of JDK versions.  If I submit a change that breaks the 
build on JDK 13, you should tell me and I should fix it. I don’t use sdkman and 
can create a JDK 13 environment easily enough from the JDK’s binary tarball. 

Julian 

> On Oct 3, 2022, at 5:38 AM, Alessandro Solimando 
>  wrote:
> 
> Hello everyone,
> I was checking a build failure
>  related to
> JDK15 and I wanted to try it locally, however I can't do it via sdkman
>  (a "multi-platform software manager") as JDK is not
> anymore available. This is not the first time, and it makes review tasks
> complicated sometimes (in this specific case it seems an ENV issue, but
> that's not the point here).
> 
> I wanted to discuss with you if we really want to keep those "recent but
> EOL" versions or not in our test matrix.
> 
> I know that JDK8 is EOL too, but lots of projects are still based on it and
> it's sadly running in PROD in many places for the same reason. In my (maybe
> limited) experience, those who upgraded to newer versions (> 11), aren't
> likely to get stuck at, say, 15 and can't move to 17. Is my assumption
> correct in your experience?
> 
> In my sdkman on MacOS I only see JDK 8, 11, 17, 20, 21, 22, and I strongly
> suspect they are following some criteria based on LTS/EOL versions.
> 
> Shall we try to do something similar for Calcite and remove non-LTS+EOL
> versions higher than 11?
> 
> Best regards,
> Alessandro

[DISCUSS] restrict JDK test matrix

[Alessandro Solimando]

Hello everyone,
I was checking a build failure
 related to
JDK15 and I wanted to try it locally, however I can't do it via sdkman
 (a "multi-platform software manager") as JDK is not
anymore available. This is not the first time, and it makes review tasks
complicated sometimes (in this specific case it seems an ENV issue, but
that's not the point here).

I wanted to discuss with you if we really want to keep those "recent but
EOL" versions or not in our test matrix.

I know that JDK8 is EOL too, but lots of projects are still based on it and
it's sadly running in PROD in many places for the same reason. In my (maybe
limited) experience, those who upgraded to newer versions (> 11), aren't
likely to get stuck at, say, 15 and can't move to 17. Is my assumption
correct in your experience?

In my sdkman on MacOS I only see JDK 8, 11, 17, 20, 21, 22, and I strongly
suspect they are following some criteria based on LTS/EOL versions.

Shall we try to do something similar for Calcite and remove non-LTS+EOL
versions higher than 11?

Best regards,
Alessandro