[
https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647033#comment-17647033
]
Konrad Windszus edited comment on JCRVLT-672 at 12/20/22 4:06 PM:
------------------------------------------------------------------
Probably using the same semantics as in
https://maven.apache.org/ref/3.8.6/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
(also described in
https://maven.apache.org/pom.html#version-order-specification) would make sense
here.
{quote}
Numeric segments are compared mathematically, alphabetic segments are compared
lexicographically and
case-insensitively. However, the following qualifier strings are recognized
and treated specially: "alpha" = "a" <
"beta" = "b" < "milestone" = "m" < "cr" = "rc" < "snapshot"< "final" = "ga" <
"sp". All of those
well-known qualifiers are considered smaller/older than other strings. An
empty segment/string is equivalent to 0.
{quote}
was (Author: kwin):
Probably using the same semantics as in
https://maven.apache.org/ref/3.8.6/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
or
https://github.com/apache/maven-resolver/blob/master/maven-resolver-util/src/main/java/org/eclipse/aether/util/version/GenericVersionScheme.java
would make sense here.
{quote}
Numeric segments are compared mathematically, alphabetic segments are compared
lexicographically and
case-insensitively. However, the following qualifier strings are recognized
and treated specially: "alpha" = "a" <
"beta" = "b" < "milestone" = "m" < "cr" = "rc" < "snapshot"< "final" = "ga" <
"sp". All of those
well-known qualifiers are considered smaller/older than other strings. An
empty segment/string is equivalent to 0.
{quote}
> Provide a Version comparison function complying to Maven version ordering
> specification
> ---------------------------------------------------------------------------------------
>
> Key: JCRVLT-672
> URL: https://issues.apache.org/jira/browse/JCRVLT-672
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Affects Versions: 3.6.6
> Reporter: Hans-Peter Stoerr
> Assignee: Konrad Windszus
> Priority: Minor
> Fix For: 3.6.8
>
>
> I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version
> that provides a sensible partial ordering for checking whether one package is
> newer than another.
> Background:
> [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157]
> provides a nice function to sort package versions e.g. for the purpose of
> displaying them in a predictable order that is close to the probable
> timeline. But sometimes you want an "is newer than" relationship - e.g. for a
> sanity check during package installation that you don't install an older over
> a newer package. As far as I know, Adobe AEM is actually (ab-)using that
> compareTo function for that purpose. That is a problem, because if you deploy
> e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3,
> it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT
> is newer than 1.2.3.
> Now, obviously you cannot fix that AEM problem here, but you could provide a
> function at Version for future use, that would be a nicely useable "is newer
> than" relationship for that purpose, and add a comment warning people not to
> use Version.compareTo for such a sanity check. That'd be nice for AEM usage,
> but also for other package managers, like our [Composum package
> manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de].
> While the ordering of the numerical prefix (which is also implemented by
> Version.compareTo) is pretty widely used, there is no widely used ordering
> for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1,
> -alpha, -testing and whatnot. So it's not possible to give a full order for
> that purpose. My suggestion is to provide a partial ordering based on the
> numerical prefix, but to ignore the suffix completely. Perhaps provide a
> function Version.compareNumericPrefix ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
