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 > <[email protected]> wrote: > > Hello everyone, > I was checking a build failure > <https://app.travis-ci.com/github/apache/calcite/jobs/584482342> related to > JDK15 and I wanted to try it locally, however I can't do it via sdkman > <https://sdkman.io/> (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
