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] > >
