Maybe I missed something but I'm rather -0 since: 1. I'm not convinced it is an issue - a surprise, everyone asked himself for sure but not an issue for 99% of dev too (maybe cause there was a ~single version until maven 4 for most dev) 2. If we start to do that we bind the maven version with the model <- there we do create an issue or we must support all models in all supported versions (which is still loosely defined) and create fake model version no more linked to distribution feature (worse for end users from my window) 3. This is something very hard to guarantee on the long run so we might get the same issue in 7 years with maven 6 4. Ultimately we miss the communcation exercise if 2 or 3 is true too quickly 5. Opens more discussions not fully solved like what about patch version management, do we enable only backward compatible changes in model minors or patches, no change at all in patches etc... 6. Plugins...current supported version is not crazy so we'll run after the latest very quickly, is it desired if there are breaking changes like between 4.0.0 and 4.1.0 (module rename is a mess for pom writers)?
So not against but I see no real life pro and at least the same cons than today to do it. 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 jeu. 22 oct. 2026 à 20:53, Guillaume Nodet <[email protected]> a écrit : > +1 > > Le jeu. 22 oct. 2026 à 20:27, Matthias Bünger <[email protected]> a > écrit : > > > > Hallo everyone, > > since decades many Maven users are confused by the fact that the version > > of Maven diverges from its counterpart in the POM model. Questions like > > "Why is the POM version 4.0.0, when I'm using Maven 3?" or "Do I have to > > migrate my POM file when I update Maven?" pop up in many chats. The > > simple answer to those is: This difference comes from a quick evolution > > of the POM model during the early days of Maven. But since the POM model > > 4.0.0 hasn't changed since Maven 2 back in 2005, this knowledge got > > forgotten, while irritation continues to rise. > > > > With the introduction of a consumer POM (see [1]) and the optional POM > > model version 4.1.0 available for the build POM (see [2]) in Maven > > 4.0.0, we see the first new model version in over 20 years. But the > > result is the same: The versions of Maven and its model are not the > > same. The definition of model version 4.2.0 was planned for Maven 4.1.0 > > - until now. > > > > The Maven team would like to align the versions of Maven and the POM > > Model version, starting with Maven 4.2.0, resulting in a version skip of > > Maven itself. This means we do not plan to release a version called > > "Maven 4.1.x". Instead, we want to raise the version to Maven 4.2.0 on > > the master branch (see PR [3]). In the future the model version would > > continuously rise with every major and minor version of Maven, while > > keeping a certain backwards compatibility - so users only have to change > > their POM file, when they want to make use of new model features. > > > > In short: > > - Maven 3.x uses POM model 4.0.0 > > - Maven 4.0 uses POM model 4.1.0 (build POM) > > - Starting with Maven 4.2, the Maven and POM model versions will align > > > > Before we finalize this, we want to get your thoughts about the change. > > Before answering, please keep in mind that: > > - this only effects the build POM of Maven, but _NOT_ the POM consumed > > by the Maven ecosystem, including Maven central and other build tools. > > The model of the consumer POM will stay at the long-known version 4.0.0. > > - this is only to wipe out the discrepancy of the Maven version and its > > POM model in favor for easier version understanding and management. It > > has nothing to do with the discussion about whether the namespace of the > > XSD should contain a number or not (as of April 2026 the majority wants > > to keep it in the namespace, see [4]). > > - the idea of aligning versions is nothing new. It was mentioned several > > times over the years, e.g. in this article of "JVM Advent" back in 2021 > > (see [5]) > > > > On behalf of the Maven team > > Matthias > > > > > > [1]: https://maven.apache.org/whatsnewinmaven4.html#consumer-pom > > [2]: https://maven.apache.org/whatsnewinmaven4.html#model-version-4-1-0 > > [3]: https://github.com/apache/maven/pull/13656 > > [4]: > https://lists.apache.org/thread.html/h6d7wgq54fr84rmd65bddnwhwnxc7g62 > > [5]: https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- > ------------------------ > Guillaume Nodet > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
