In general, dropping older JDKs and updating the CI makes sense for the BookKeeper server. Here comes the problem that we want to maintain the BK client with lower JDK compatibility, even if it is EOL. Companies still use older JDKs, pay to 3rd party vendors to maintain the JDKs/provide the security patches etc.
BK's client builds with the server which bring up this ancient issue: https://github.com/apache/bookkeeper/issues/617 In short, IMO it would make sense to split the client into a separate module first, build and run tests for the client using older JDKs and maintain the server with more current JDKs. On Sun, May 26, 2024 at 6:17 PM ZhangJian He <shoot...@gmail.com> wrote: > Hi, BookKeepers, I want to propose and clarify a new CI strategy based on > our former practices. > > ## Current CI Jobs > > - **PR Validation Tests**: Currently, these jobs run on JDK 11 for every > pull request to ensure all changes meet our quality standards before > merging. > - **Platform Build Tests**: We run Windows and macOS builds on JDK 11. > - **Tests**: Major tests are currently only run on JDK 11 due to time > constraints(I think, please point out if I were wrong). > - **Compatibility Checks**: We perform basic compatibility checks across a > JDK matrix of 8, 11, 17, and 21, with JDK 21 added recently as per [this > pull request](https://github.com/apache/bookkeeper/pull/4350). > - **OWASP Check**: Run as part of our daily builds or pom file changes to > ensure security vulnerabilities are identified and addressed swiftly. > - **Daily Builds**: These are three types of job in daily builds: higher > jdk linux, owasp, windows jdk(current running in jdk21, limited to some > development jobs, there are still many tests failures to be solved), due to > its speed and the ability to expose issues. > - **GitHub CodeQL, TYPOS**: These jobs are not related to JVM. > > ## Proposed JVM Strategy > > Given that JDK 11 will reach its end of life in October 2024 [1], I suggest > transitioning our main CI operations to **JDK 17**. This would include the > `PR Validation Tests`, `Platform Build Tests`, and `Tests`. > > For `Compatibility Checks`, we should consider maintaining checks only for > OpenJDK LTS versions that are not EOL. For instance, we can remove JDK 11 > from the compatibility matrix after October 2024. > > For `Daily Builds` on Linux, I propose adding OpenJDK LTS versions beyond > our main CI version. > > For `Daily Builds` on Windows and the `OWASP Check`, using the latest > OpenJDK version will leverage the most advanced and supported JDK features > and help expose more problems. > > Thank you for considering this strategic update. I look forward to your > feedback and further discussion. > > [1] [JDK 11 End of Life Update](https://access.redhat.com/articles/1299013 > ) > > Thanks > ZhangJian He > Twitter: shoothzj > Wechat: shoothzj > -- Andrey Yegorov
