Le dim. 16 mars 2025 à 21:56, Elliotte Rusty Harold <elh...@ibiblio.org> a écrit :
> -1 > > I don't think we're anywhere near ready to finalize 4.0. The more I > look at it, the more issues I see. > > https://issues.apache.org/jira/browse/MNG-8537 is perhaps the most > critical > This issue mentions several changes. Some of those are simple bugs and can be easily fixed or delayed (for example the fact that Maven isn't rejecting models without namespaces is just a bug, see last point below). It also mentions namespace problems, but the only ref I found is a minor bug in the xinclude extension. As for the original issue, changing the namespace, this requires a dedicated discussion. Several points to consider: * it has been in master for at least 18 months and nobody complained. Given Maven 3 POMs may NOT be XML-conformant, I don't think any real xml processing tool is actually processing those POMs, so changing isn't a big deal imho. * changing the namespace is a clear sign of a change in the expectations imho: we do want to be XML conformant from now on * if we want to go forward and not change the schema namespace uri in the future, we should start by using an unversioned uri such as http://maven.apache.org/POM/ * this would obviously break the fact that the modelVersion is now inferred, but... * note that we already have elements in 4.0.0 which have been deprecated in 4.1.0. For compatibility, they are being kept, but the idea would be to get rid of those in the next schema version, which makes the schema incompatible. So what will happen ? AFAIK, the best practice is to change the namespace in such a case, so... * fwiw, we don't use schema validation (and for performance reasons, I don't think we should at this point) * and we absolutely no way currently to support multiple breaking schemas So in short, Maven 3 was not even XML conformant, so I don't think reusing the same namespace makes a lot of sense. Currently, we're leaning more towards using multiple versions of the schema, and thus removing the modelVersion, because it's redundant. We can change and use a single version going forward and use a modelVersion (or maybe just "version" then) going forward. However we need to know what strategy we'll use when it comes to breaking changes. We also need to finish the API. Most of it right now is experimental: > https://issues.apache.org/jira/browse/MNG-8485 It's all of it, not most of it. And I don't think we have to. We can ship the new API in "Preview" mode, just like OpenJDK does with new APIs. If really the community is bothered with the @Experimental annotation, I'm fine removing it, but then we risk mis-communicating expectations to our users, which is imho, worse. Or maybe rename @Experimental to @Preview ? We also need to disallowing version 4.0 poms without a proper namespace, > We just can't. Nor can we fix everything that's on Maven central. And that's the reason why we can't. But note that for newly deployed consumer POMs already always have a proper namespace and are XML conformant. Also, the model reader has a strict mode which is used when reading POMs that are being built, and a lenient mode which is used when consuming POMs downloaded from Maven Central. Btw, would it be possible to ask Sonatype to add additional validation rules wrt allowing POMs in Maven Central ? We can enforce it in Maven for consumer POMs created by Maven, but we should enforce them when publishing the POMs, in particular for POMs that are crafted by other tools such as Gradle and such. We should make sure they can be safely consumed before they reach Maven Central. > There are others. Those are just the most pressing ones off the top of > my head that it's much less expensive to fix now than after we ship. > > On Sun, Mar 16, 2025 at 4:37 PM Guillaume Nodet <gno...@apache.org> wrote: > > > > I think it's time to create a branch to release Maven 4.0.0 GA in the > > coming weeks and switch master to 4.1.0-SNAPSHOT. > > Thoughts ? > > > > -- > > ------------------------ > > Guillaume Nodet > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ------------------------ Guillaume Nodet
