Re: [DISCUSS] Should Maven 4 prioritize forward evolution over full Maven 3 compatibility?

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