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]
