For Gradle upgrades, there’s only one place to modify. Add a comment in gradle/wrapper/gradle-wrapper.properties reminding people to also howto.md.
For Java upgrades, there aren’t many places to modify. But supporting a new Java version warrants a Jira case (whose headline is the Java upgrade) and review. That should suffice. Julian > On Dec 21, 2021, at 11:21 PM, Vladimir Sitnikov <[email protected]> > wrote: > > Julian, I know it might be tough, yet: > 1) I would like you to believe me I just forgot howto and the other places > hard-code Java versions. > Of course, "we support Java 17" is a notable change, and it does deserve to > be in the release notes, > however, the typical current process is to "file JIRA for notable changes", > so I did just that, and created > CALCITE-4829 Bump Gradle to 7.2 and test with Java 17 at GitHub Actions. > > I agree it is unclear how the release manager could deduce they should add > "Calcite X.Y supports Java 17 now" to the release notes. > However, I am sure that could have happened with ANY change. > The release manager often is not in a position to judge which changes are > notable for the release. > > 2) I previously suggested we should automate the replacement of "the > maximum supported Java". > I believe the current failure highlights that once again. > We can never expect contributors to remember all the places Java versions > can be mentioned. > > ----- > > Julian>then the following tasks need to be done: > Julian>Update the Gradle version in howto.md... > > I am afraid it does not solve the root cause, so we should do something > different. > New Java and Gradle versions would appear, and we would keep forgetting to > update all the places. > > I suggest we add a variable like max_tested_java_version somewhere > (gradle.properties? somewhere else?) > Then we use the variable for building the website and we would check CI > does test with the given version. > > ^^^ this suggestion will stop those discussions once and forever. > That is basically the same thing I suggested in CALCITE-4575. > >> Does Calcite now support Java 16 and 17? > > 17 is available, so there's no point in mentioning "Java 16 is supported". > > Current text: > >> Building from a source distribution >> Prerequisite is Java (JDK 8, 9, 10, 11, 12, 13, 14 or 15) and Gradle > (version 7.2) on your path > > I would suggest: > >> Building from a source distribution >> Prerequisite is Java 8 to ${max_tested_java_version} and Gradle (version > ${gradle_version_from_wrapper}) on your path > > Julian>Change the subject of > Julian>https://issues.apache.org/jira/browse/CALCITE-4547 to "Support Java > 16 > Julian>and 17", > > -0.97 for mentioning "support Java 16" > We do not support that version, we do not test with Java 16, and we do not > want to add > Java 16 tests as it would significantly increase test times. > We just hope it would work. > > Of course, most likely Calcite would work with Java 16 since Calcite works > with 11 and 17. > However, please, Julian, please, let us stop mentioning that we support > irrelevant versions? > None of Java vendors provide LTS for 16. > > Vladimir
