[
https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648031#comment-17648031
]
Hans-Peter Stoerr commented on JCRVLT-672:
------------------------------------------
[~kwin] :
Ouch! It seems I've unknowingly opened a can of worms there. The maven
versioning oder specification
https://maven.apache.org/pom.html#Version_Order_Specification
is amazingly complex when it comes to parsing and comparing the stuff after the
first dash. There are also other
differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo
doesn't so far.
For a start: maven segments versions differently: in addition to - and . it
separates digit sequences from non-digit
sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the
ordering depends on whether the
separators are - or . (digit vs. non-digit separation is treated as -). We
could change Version.getNormalizedSegments
() to also split on digit / non-digit sequences, but it wouldn't be enough to
determine the ordering, anyway, and
that also would have a risk of breaking something.
I guess the only way to be 100% compatible to maven would be to copy e.g.
[ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java]
as
a package private class into org.apache.jackrabbit.vault.packaging and use that
for comparisons.
That is, obviously, also the easiest way to solve the problem. One problem with
this is that the segmentation that is done to compare the versions is not quite
compatible with Version.getNormalizedSegments(), which might be confusing at
times.
Or we could make some kind of compromise that behaves the same for more common
things.
Do you have any opinions on that which help narrow down the solution space?
> Provide a Version comparison function for "is newer" checks
> -----------------------------------------------------------
>
> 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
> Priority: Minor
>
> 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)
