Hi Josh, I would relax a bit your statement about java and python, yes people can be stucked on some version but the will to move forward is often hard and it is worse for end user machines so not being too aggressive - as gradle can be - is good. Now, as always, there is a good "middle position" and maven 4 with an official API we do totally own should provide more stability for plugins and extensions which is the main reason of the compatibility nightmare we might have in some area. So long story short, hopefully maven 3-4 will be the latest that hurtful period, future ones - will still happen but - will be smoother normally.
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via linkedin) Le ven. 14 août 2026 à 08:16, Josh Biily <[email protected]> a écrit : > 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] > > > > >
