Hi, the package comparison is great and while I agree on everything written there it also means we do go with a new namespace cause we'll break module for subproject. so either we do revert these changes long term (subprojects, sources etc) or we might just have to keep the new namespace to be consistent with what you do expose no?
side note: I can hear we mitigate the breaking changes now and keep it for next time but it is going back to fall from higher later so we must decide now how we'll solve the drop of <module> now IMHO and namespace/modelVersion is a clean way 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 founder (Java/.NET service - contact via linkedin) Le dim. 5 avr. 2026 à 09:24, Martin Desruisseaux via dev < [email protected]> a écrit : > Le 05/04/2026 à 07:55, Mirko Friedenhagen a écrit : > > > I thought the idea of maven 4 was to prepare for faster moves and > enabling breaking changes like e.g. one-line-gav definitions possibly with > attributes. java.util to my knowledge never broke compatibility while > javax/jakarta did so mostly for corporate licensing. > > Yes, this is the idea. The Maven 4 POM does not break compatibility > compared to Maven 3 POM. It adds a few new elements, but did not changed > the semantic of previous elements. This is equivalent to adding new > classes in a package without breaking the existing classes. We don't > rename package in such situation. The same argument applies to the XML > namespace. > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
