[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807331#comment-17807331
]
ASF GitHub Bot commented on MRESOLVER-336:
------------------------------------------
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453678801
##########
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:
Got it, I misinterpreted the goal of this change so I was getting worried
about potential breaking changes versus better/clearer behaviors. But as we're
not updating behaviors, I'm fine with this description as it stands.
> 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)
