JDK 8 active support ended 15 months ago, so I think that's definitely fine to require a newer version. I don't think we should wait and support JDK 8 until 2030 and then switch from JDK 8 to what, JDK 24 ? That's really not a good plan imho and that's what maintenance branches are used for. The JDK release cycle has changed and the whole java ecosystem is adapting to this faster release cycle.
So I think we should: * maintain a 3.x branch with JDK 8 and provide bug fixes * set up 4.x branches to require at least the oldest actively supported JDK at the time the first micro version is released (so that would be 17 by the time 4.0.0 comes out) and 21 by the end of 2026 (maybe 4.2.0 ?) JDK 17 can still target JDK 8 for compilation, so that should cover most needs. If needed, we could even automatically download a JRE 17 at first usage (using [1] but we'd have to check for upgrades, etc...) and continue the work for discovering toolchains [2], etc... to help users. We could also make JDK toolchains much easier to use by modifying the project model and adding specific support for it. That would allow selecting the toolchains very early in the build, thus allowing toolchain based jdk activation, and would make the configuration much simpler. Though I have a feeling that all this is not really necessary... Guillaume [1] https://foojay.io/ [2] https://github.com/apache/maven-toolchains-plugin/pulls Le mer. 31 mai 2023 à 21:17, Michael Osipov <micha...@apache.org> a écrit : > I also would like to point out that OpenJDK 8 support will surpass 11 by > 2030: https://endoflife.date/java > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
