I argument I heard here that was quite compelling was to update the requirement in order to make it easier to port code to Maven 4.0 (assuming APIs are now deprecated in 3.10)
2c, Gary On Fri, Oct 9, 2026, 05:04 Gerd Aschemann <[email protected]> wrote: > I’d also prefer to nominate a mature version as baseline than a “fresh > release”. > > > On 9. Oct 2026, at 10:33, Hervé Boutemy <[email protected]> wrote: > > > > thinking at it: > > we documented Maven 3.9 as a minimum "because 3.8 EOL'ed", the same way > we did earlier > > > > IMHO, EOL'ed older version is not the only driver: > > the key driver is that we have a newer version that is now proven > rock-solid > > > > we went to Maven 3.9 as minimum prerequisite when we had released Maven > 3.9.10, that was really known as a very good level bugfix confidence > > > > > > > > to me, it is that approach that we need to keep > > > > > > On 2026/10/09 00:15:02 Hervé Boutemy wrote: > >> Maven 3.9 as a minimum was already decided and documented in October > 2025 > >> > https://github.com/apache/maven-site/blame/master/content/markdown/developers/compatibility-plan.md > >> > >> this is a great plan to implement > >> > >> > >> on upgrading minimum to 3.10, it's definitively too early: > >> remember 3.10 is resolver 2, a transition for Maven 4, and is out just > a few days ago, we're still at 3.10.0 > >> > >> > >> on shared-utils and styled message API: > >> I get that reverting back from shared-utils to plexus-utils makes > shared-utils too big on overlapping classes. > >> Styled message API is the only part of shared-utils that should remain, > as it is where the code landed to NOT depend on Maven core. > >> > >> Why not create a new release of shared-utils that contains just the > styled message API? > >> This would remove the overlap with plexus-utils, while not introducing > a prerequisite on Maven 3.10 > >> > >> > >> Regards, > >> > >> Hervé > >> > >> On 2026/10/07 21:32:45 Slawomir Jaranowski wrote: > >>> Hi, > >>> > >>> Today I will go with 3.10.0 we have new API [1] like > >>> - MessageBuilderFactory - we can drop maven-shared in many plugins > >>> - we have java version in JavaToolchain > >>> > >>> 3.10.0 was released 2026-09-27 and I can see many issues with it ... > >>> form some of days 3.10.0 is default on GH runners [2] > >>> > >>> > >>> [1] > >>> > https://maven.apache.org/docs/3.10.0/release-notes.html#new-api-and-updates-for-maven-plugins > >>> [2] https://github.com/actions/runner-images/releases > >>> > >>> > >>> On Wed, 7 Oct 2026 at 23:09, Sylwester Lachiewicz < > [email protected]> > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> A year ago we discussed the minimum Maven version for ASF plugins [1]. > >>>> Slawomir proposed four options, and his summary on 2025-11-13 lists > ten > >>>> +1s for > >>>> 3.9.0. The compatibility plan was updated accordingly [2][3]: > >>>> > >>>> "In October 2025, Maven before 3.8.3 has been marked as EOL, meaning > that > >>>> plugins should use 3.9.0 as minimum (as per Mailing List)" > >>>> > >>>> Many plugins still declare <prerequisites><maven>3.6.3</maven>, so I > would > >>>> like > >>>> to clarify what that thread decided. Two questions: > >>>> > >>>> 1. Was that thread a formal vote, or a show of hands to be confirmed > by a > >>>> [VOTE]? > >>>> 2. Should we raise the prerequisite to 3.9.0 across our plugins, or > keep > >>>> the existing 3.6.3 and update the compatibility plan to reflect that? > >>>> > >>>> This is only about the outcome of last year's thread. This is only > about > >>>> the outcome of last year's thread. It is not Maven 3.10.0 or about > adopting > >>>> new APIs. > >>>> > >>>> [1] https://lists.apache.org/thread/s2dvm1jg37vhrkkkplfknk494c68zfyv > >>>> [2] https://github.com/apache/maven-site/pull/1456 > >>>> [3] https://maven.apache.org/developers/compatibility-plan.html > >>>> > >>>> Regards, > >>>> Sylwester > >>>> > >>> > >>> > >>> -- > >>> Sławomir Jaranowski > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- > Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas) > +49/173/3264070 -- [email protected] -- https://aschemann.net > >
