[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807285#comment-17807285
]
ASF GitHub Bot commented on MRESOLVER-336:
------------------------------------------
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453479693
##########
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:
Why would these qualifiers not *always* be zero segments? For example I
could have `1.0.final.1`; if I then decided to have `1.0.1.final` I'd be more
likely to expect it to come later than `1.0.final.1` than to have it come
before. And having context-sensitive rules is problematic for parsing IMO; it's
better if two segments can always be compared in complete isolation than for it
to depend on what comes before or after it. I'd use this absolute segment
ordering (lowest to highest) in all cases:
* `min`
* qualifiers in order
* `alpha`/`a`
* `beta`/`b`
* `milestone`/`m`
* `rc`/`cr`
* `snapshot`
* zero segment
* empty string
* `final`/`ga`/`release`
* zero
* qualifiers in order
* `sp`
* other strings (lexicographically)
* positive integers (numerically)
* `max`
> 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)
