Hans-Peter Stoerr created JCRVLT-672:
----------------------------------------
Summary: 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
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 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, it'll refuse automatical
installation because it 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.
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)