just landed :) happy that 4.0 vs 4.1 clarifies things: in fact, what we currently have in 4.1 is what I called Maven 5 in 2021 https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html
there is one key feature that initially should have waited for 4.1/5 but is in 4.0 to prepare all the plugins alongside: this is Java Module native build (because this is strategic and we have great experts giving a lot of efforts, experrience and time for it) = https://cwiki.apache.org/confluence/spaces/MAVEN/pages/393677487/Full+Java+Modules+Support+-+Current+State we have so many proposals about gav XML simplification that just consolidating all good ideas that were written in the past will be a big task (search in GH issues, in Wiki, and in a lot of places) whoever has the energy to start that consolidation is welcome Regards, Hervé On 2026/08/14 06:15:49 Josh Biily wrote: > Hi Hervé, > > Thank you for the detailed explanation. This makes the current Maven 4.0 > strategy much clearer to me. > > I especially like the distinction between "reasonable compatibility" and > perfect compatibility. Supporting existing Maven 3 plugins enough to let > users cross the bridge first, and then allowing Maven 4.1+ to move more > aggressively forward, sounds like a very practical approach. > > Your "cut the bridge behind us, not in front of us" analogy explains the > strategy very well. > > I am also glad to hear that GAV/XML simplification is already being > discussed internally. For everyday users, improvements like that are highly > visible and can make Maven 4 feel like a real new generation, not only an > internal architectural upgrade. > > I will keep an eye on RC7 and the 4.1 work. Thanks again for taking the > time to explain the plan. > > Best regards, > Josh > > On Fri, Aug 14, 2026 at 12:39 PM Hervé Boutemy <[email protected]> wrote: > > > I forgot to add a few key links: > > > > - we have the first layer of syntactic sugar in place in 4.0, to prepare > > the next ones you are asking for (that would not be reasonable for a first > > step): > > see https://maven.apache.org/whatsnewinmaven4.html > > > > - we have the compatibility tests and users migration process: > > see https://maven.apache.org/guides/mini/guide-migration-to-mvn4.html > > > > - we have the first strong improvement in Maven 4.1 already documented = > > mixins, just don't talk much about it because we need to focus on 4.0 > > before 4.1: > > see https://maven.apache.org/guides/mini/guide-mixins.html > > > > > > your feedback proves me that the hard discussion about the gav XML pattern > > simplification should probably be our next key hot discussion... > > we have people ready for that, we just asked them to ait a little bit for > > now... > > > > > > On 2026/08/14 04:28:27 Hervé Boutemy wrote: > > > very good question > > > > > > the key topic is the huge community-provided Maven plugins: we cannot > > just ignore them, this would be detrimental to both maintainers and users > > > = force new Maven 4 users to wait for every plugin maintainer to create > > a new Maven 4 plugin > > > > > > that's why we have a *reasonable* Maven 3 plugins in Maven 4 plan. > > > here, *reasonable* is key: not for Maven 3 plugins that use Maven 2 > > compatibility layer = no, that one would be too much > > > > > > > > > We communicate a lot on this compatibilty aspect for Maven 4.0, and > > smooth transition to the new POM model, because it's a key scope for a > > first wave of safe usage and transition for everybody > > > > > > but don't worry: Maven 4.1 is in progress in parallel, with more of what > > you are implicitely asking for and that we are also willing. We just had to > > clarify our Maven 4.0 focus first. > > > > > > Maven 4.0 will be out soon with that "good" (not perfect, perfection > > cannot be a reasonable objective) compatibility for safe transition > > > > > > then we can safely focus on 4.1 and more aggressive "forget Maven 3" > > plan: we have the first step in place now to be able to cut the bridge > > behind us, not in front of us :) > > > > > > > > > We can go more in tech details, but this is the plan that is currently > > landing with good confidence: time between RC5 and 6 was too long, we're > > now ready for a quick RC 7 and 4.0.0 very soon > > > > > > Plugin maintainers, users: please help us testing with 4.0 RC6 and 4.0 > > RC7, as this is the last call before 4.0 (I'm currently in an airport, this > > is the last call for my flight :) ) > > > > > > Hope this clarifies your good concerns > > > > > > Hervé > > > > > > On 2026/08/14 02:27:07 Josh Biily wrote: > > > > Hello Maven developers, > > > > > > > > English is not my native language, so I hope you can understand if some > > > > wording is not perfectly precise. > > > > > > > > I would like to raise a design and release-strategy question about > > Maven 4. > > > > > > > > This is not intended as a complaint about Maven 4 development speed or > > the > > > > work already invested in compatibility. Maven is critical > > infrastructure > > > > for the Java ecosystem, and I understand why backward compatibility > > matters. > > > > > > > > My question is whether Maven 4 may be carrying too much compatibility > > > > responsibility for Maven 3. > > > > > > > > My main thought is: > > > > > > > > Maven 3 can continue to serve existing and legacy projects, while > > Maven 4 > > > > can focus more aggressively on new projects and the future Java > > ecosystem. > > > > > > > > We already accept this model elsewhere. > > > > > > > > Many companies still run Java 8 applications today. Those projects may > > > > remain on Java 8 for years because stability is more important than > > > > upgrading. That does not prevent Java 17, 21, or 25 from moving > > forward. > > > > > > > > Spring Boot is another example. Many production systems still use > > Spring > > > > Boot 2.x, while Spring Boot 3 moved to Java 17 and Jakarta EE with > > > > significant breaking changes. Existing Boot 2 applications did not > > need to > > > > migrate immediately, but their existence did not prevent newer > > generations > > > > from evolving. > > > > > > > > Python 2 and Python 3 provide a stronger example. Old Python 2 > > applications > > > > could remain on Python 2 while Python 3 continued to evolve. Migration > > was > > > > optional and happened when the benefits justified the cost. > > > > > > > > I wonder whether Maven could follow a similar model: > > > > > > > > - > > > > > > > > Maven 3 remains a stable maintenance line for legacy projects. > > > > - > > > > > > > > Existing Java 8/11 projects and old plugin ecosystems can continue > > using > > > > Maven 3. > > > > - > > > > > > > > Maven 4 primarily targets modern Java projects, for example Java > > 17+. > > > > - > > > > > > > > Maven 4 may introduce carefully chosen breaking changes when they > > > > provide substantial improvements in architecture, APIs, performance, > > > > maintainability, or developer experience. > > > > - > > > > > > > > Projects that do not need Maven 4 are not required to migrate. > > > > - > > > > > > > > Projects that want Maven 4 can migrate when the benefits justify it. > > > > > > > > In other words, backward compatibility would still be important, but > > > > perhaps it could be treated partly as a migration problem rather than > > as a > > > > requirement that every Maven 3 project and historical behavior work > > > > unchanged under Maven 4. > > > > > > > > A compatibility checker or migration tool might sometimes provide more > > > > value than perfect compatibility. For example, a future tool could > > report: > > > > > > > > - > > > > > > > > incompatible plugins > > > > - > > > > > > > > deprecated or removed APIs > > > > - > > > > > > > > unsupported POM behaviors > > > > - > > > > > > > > model differences > > > > - > > > > > > > > required migration steps > > > > > > > > The practical reason I think this distinction matters is that the > > projects > > > > most dependent on old Maven behavior are often also the least likely to > > > > upgrade Maven. > > > > > > > > A stable Java 8 application with old plugins and a mature build > > pipeline > > > > may intentionally remain unchanged for many years. Ensuring that such a > > > > project can use Maven 4 without modification may require substantial > > > > engineering effort, even though its maintainers may never plan to move > > to > > > > Maven 4. > > > > > > > > Meanwhile, new Java 21 or Java 25 projects are more likely to adopt > > Maven 4 > > > > and may benefit from improvements that are difficult to introduce under > > > > very strict Maven 3 compatibility constraints. > > > > > > > > So perhaps the two goals could be separated more explicitly: > > > > > > > > Maven 3 prioritizes stability and compatibility. > > > > > > > > Maven 4 prioritizes forward evolution. > > > > > > > > These goals do not necessarily conflict. A stable Maven 3 line gives > > > > existing users a safe place to remain, and that stability may actually > > give > > > > Maven 4 more freedom to evolve. > > > > > > > > I also think this could help Maven 4 provide more visible benefits to > > > > everyday users. > > > > > > > > For example, common dependency declarations are still verbose: > > > > > > > > <dependency> > > > > <groupId>org.apache.commons</groupId> > > > > <artifactId>commons-lang3</artifactId> > > > > <version>3.18.0</version> > > > > </dependency> > > > > > > > > For common cases, a future POM model could theoretically support > > syntactic > > > > sugar such as: > > > > > > > > <gav>org.apache.commons:commons-lang3:3.18.0</gav> > > > > > > > > while keeping the traditional <dependency> form for complex cases. > > > > > > > > This is only an example, not the main proposal. My broader point is > > that a > > > > major version should ideally have enough user-visible improvements to > > give > > > > developers a reason to adopt it, even if some improvements require > > > > carefully documented incompatibilities. > > > > > > > > I am not suggesting that Maven 4 should break compatibility casually. > > > > > > > > I am suggesting that compatibility may benefit from having a > > cost-benefit > > > > threshold. If preserving a Maven 3 behavior significantly delays Maven > > 4, > > > > complicates its architecture, or prevents meaningful improvements for > > > > modern projects, documenting the incompatibility and providing a > > migration > > > > path may sometimes be the better trade-off. > > > > > > > > Would the Maven team consider formally treating Maven 3 as the > > long-term > > > > stability/compatibility line, while allowing Maven 4 more freedom for > > > > carefully chosen breaking changes aimed at modern Java projects? > > > > > > > > I would be interested to hear how the Maven team currently thinks about > > > > this trade-off. > > > > > > > > Thank you for your work on Maven. > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
