Edit version comparison #1714
Edit version comparison #1714
Conversation
| * <p> | ||
| * Version string is parsed into version according to these rules: | ||
| * A version string is parsed according to the | ||
| * <href='https://maven.apache.org/pom.html#Version_Order_Specification'>Version Order Specification</a>. |
There was a problem hiding this comment.
Nope. The refd URL points to maven-artifact spec, that is known to differ from this one (see resolver/maven issues). In Maven 4 the Resolver Version is becoming "the standard" (as new Maven4 API delegates to it), and maven-artifact module is put under compat/, as it is being deprecated with many other things there.
Goal is to stop this current split-brain situation, and duplication of this very important aspect of Maven. Moreover, maven-artifact class Artifact is basically a mixed bag of dependencies (has scope etc) and artifacts. That thing should be just forgotten.
There was a problem hiding this comment.
Or, align the site page with Resolver GenericVersion, then it could be fine to point there.
But the goal is to stop having this duality, duplication and keep trying to align these two classes, aside maven-artifact one is being totally overloaded with other things as well. Just stop pouring energy into it.
There was a problem hiding this comment.
Yes, the goal here is precisely to stop the split brain problem where different docs say different things and sometimes contradict each other. The page in question at https://maven.apache.org/pom.html#Version_Order_Specification is the primary Maven documentation from the maven-site repository. It is not tied to maven-artifact, maven-resolver, or any other plugin or particular code. That's important since this is used and depended on by multiple projects. Most importantly this is user documentation for anyone who needs to understand why a dependency tree is resolving the way it is.
It is also important to provide a normative spec for anyone implementing this. For historical reasons, this is a little backwards and some of this is reverse engineered from what the code has been doing for over two decades now rather than planned out up front. Ideally we would have started with a clear and unambiguous spec and built the implementation from that.
Going forward, any additional implementations should start from the spec rather than trying to duplicate code or algorithms. (Yes, other implementations do exist outside the maven project.) I also want to prevent unconsidered changes to the algorithm that sneak in through random PRs. Example: min/max version specifiers that got added 12 years ago, introduced a new supply chain attack, and don't seem to have ever been documented. :-(
2 participants
Mostly just wording, but also remove warning about future enforcement that is unlikely to happen.