Well, *my* pet-peeve regarding transitive dependencies (#10 <https://github.com/apache/maven/issues/10786>786 <https://github.com/apache/maven/issues/10786>, formerly known as MNG-8099 <https://issues.apache.org/jira/browse/MNG-8099?redirect=false>) is also not in, but I would never think that Maven 4 should be delayed because of that. :-)
If you want to wait until every last issue is resolved, you're simply never going to ship anything. Another old saying: Perfect is the enemy of good. Software, especially collaborative efforts, will *always* be "undergrad papers". And that's how open source (and science) moves forward. Maven 4.0 improves a lot of things, it absolutely should be released. If the APIs aren't perfect, there's always a Maven 4.1. And if bigger things need fixing, just make a Maven 5. But not releasing anything doesn't help anybody. Just my 0,02€... Now back to the actual topic of this thread: I'm missing some step for verification of the new release "in the wild", with as many different projects as possible. Aren't there any statistics on how often the RCs got used? - Henning Am Fr., 13. Feb. 2026 um 16:54 Uhr schrieb Elliotte Rusty Harold < [email protected]>: > IMHO Maven 4.0 is not close to ready for release. The most serious > issue is the change of namespace. That's a major mistake that will > cause large problems for developers, especially those who use tools > other than Maven itself. > > Second most serious issue is finalization of APIs. @Experimental > features need to be committed to or removed. > > Similarly APIs have been deprecated but not documented with > replacement. That also needs to be finished. > > Finally much of the new API is unnecessarily complex with unneeded > separation of basic functionality like URLNormalizer into separate > interfaces, implementations, services, and default implementations > when all that’s needed is one single class with a few static methods. > > All of this can and should be fixed before release. Much of it cannot > be fixed after release. > > There’s an old saying about undergraduate papers: they’re never > finished, just submitted when the deadline comes. That’s what’s going > on here. Maven 4 isn’t close to a finished product, and it’s not clear > it has the resources or will to be finished, so there’s an urgency to > push something out the door, ready or not. However, pushing it out in > an unfinished state risks doing severe damage to the developer > community and Maven’s reputation. It is better to ship nothing than to > ship a half-baked product, discouraging as that is to the people who > have been working on it. > > On Thu, Feb 12, 2026 at 5:10 PM Matthias Bünger <[email protected]> > wrote: > > > > Good evening everybody, > > last week a small number of commiter and PMC had a chat about the > > current situation about Maven 4.0.0. > > Nobody of the people attended was aware of any outstanding blocking > > issues, but also nobody could precicle say what else needs to be done > > for a GA release. As a result we collected some points on a wiki page > [1]. > > > > Today Benjamin asked me to send a mail to the list, to gather feedback, > > if we missed anything . Do you agree with the points on the list or do > > you see any (and if yes, which) blocker that needs to be done, before we > > can consider a 4.0.0 GA? > > > > Please note: This discussion should focus on "What's need to be done for > > 4.0.0". It's not about discussions about will there new RC or was RC5 > > the last RC. This can be discussed when we have a complete (as possible) > > list of TO-DO's. So please avoid to restart any discussion about > > alpha/beta/RC versions in this thread. What happend, happend (including > > new features, like Maven Update tool, during RC phase) - thank you. > > > > Matthias > > > > [1]: > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- > Elliotte Rusty Harold > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
