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

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.