Hi,
What is the concern with building using the latest LTS version (25 as of today) while still targeting Java 8 using the release javac flag? What am I overlooking? Thanks! ---- On Sat, 07 Feb 2026 11:22:09 -0500 [email protected] wrote ---- Hi, as we all expect that it will take years that the majority of users will switch to Maven 4, we still have to support Maven 3 as surefire is one of the core plugins. Lifting the required Java version for a 3.x surefire (or any other plugin), therefore requires a lifting of the minimum Java version of Maven 3. So we need to find a fix or call Surefire 3.x EOL due to this. And as an information: Windows is used a lot in dev teams, esp in those companies with heaving policies. Regarless of the rising ignorance of Windows users I agree on this statement: >> The idea I mentioned in another thread [2] is to keep aligning Surefire with the model we already use for the rest of the codebase (plugins, shared components, etc.): - 3.x branch, versioned as 3.x, Core API 3.x (i.e. Java 8 support) - master branch, versioned as 4.x, Core API 4.x (i.e. Java 17 support) This is a pattern we’ve consistently adopted across all plugins. I don’t really see why we should change it here. >> so a +1 (nb) to create a 4.x version and a 3.x release branch Am 07.02.2026 um 05:29 schrieb Olivier Lamy: > The idea I mentioned in another thread [2] is to keep aligning > Surefire with the model we already use for the rest of the codebase > (plugins, shared components, etc.): > - 3.x branch, versioned as 3.x, Core API 3.x (i.e. Java 8 support) > - master branch, versioned as 4.x, Core API 4.x (i.e. Java 17 support) > > This is a pattern we’ve consistently adopted across all plugins. I > don’t really see why we should change it here.
