[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807329#comment-17807329
]
ASF GitHub Bot commented on MRESOLVER-336:
------------------------------------------
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453671982
##########
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##########
@@ -25,5 +25,38 @@
* <p>
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * <h1>Generic Version Spec</h1>
+ * Version string is parsed into version according to these rules below:
+ * <ul>
+ * <li>The version string is parsed into segments, from left to right.</li>
+ * <li>Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.</li>
+ * <li>Segments are implicitly delimited by transition between digits and
non-digits.</li>
+ * <li>Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.</li>
+ * <li>Numeric segments are sorted numerically, ascending.</li>
+ * <li>Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.</li>
+ * <li>Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ * <ul>
+ * <li>"alpha" (== "a" when immediately followed by number)</li>
+ * <li>"beta" (== "b" when immediately followed by number)</li>
+ * <li>"milestone" (== "m" when immediately followed by
number)</li>
+ * <li>"rc" == "cr" (use of "cr" is discouraged)</li>
+ * <li>"snapshot"</li>
+ * <li>"ga" == "final" == "release"</li>
+ * <li>"sp"</li>
+ * </ul>
+ * </li>
+ * <li>String segments are sorted lexicographically, per ROOT locale,
ascending.</li>
+ * <li>There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.</li>
+ * <li>As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.</li>
+ * <li>When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.</li>
Review Comment:
Again, I have a feeling we are drifting away in a sense... If one given
project releases `1.0-1` and subsequently `1.final-1` I'd say they are not
consistent in their versioning. People/projects usually have (or agree on)
"version format" and stick to that. There are atypical cases like you brought
up (starting with qualifier) but in real life I don't think anybody uses
versions like that. Similarly, "sorting" (ordering) of versions happens usually
within same GA, so "same project", hence same "version format" can be assumed.
Maven never sorts (wildly different) versions from Maven Central... nor is
meant to support use case like that.
What I want to say, that we can and will probably find countless examples of
"what if..." versions, but we should really limit ourselves to real examples.
> Unexpected handling of qualifiers in GenericVersionScheme
> ---------------------------------------------------------
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Affects Versions: 1.9.5
> Reporter: David M. Lloyd
> Assignee: Tamas Cservenak
> Priority: Major
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
> 0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
> ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
