Closed gsmet closed 10 months ago
For background on this problem, see:
Long story short, the Maven version scheme has changed incompatibly at least twice. I considered the possibility of having multiple schemes depending on the Maven version in question but I think what I will do is just reimplement it to support the current scheme and hope they don't change it again.
Well, at least in this case, they have fixed something so I think it's a good thing.
My solution is to stop using the maven-artifact
scheme and use the maven-resolver
one instead (they're different!), and add a few more tests to ensure we're fully consistent. Part of this involved a minor internal enhancement to make it easier to compare against "zero" versions (because in Maven, versions like "CR1" or "beta" are considered to be less than zero).
Hmmm, I'm using maven-artifact
ComparableVersion
to work around the issue so I'm surprised you have to switch to something else?
The problems you're going to run into with maven-artfact
are bit more obscure, like differing precedence of -
versus .
separators, and the fact that maven-resolver
also treats _
as a separator. The problems I was running into were a result of twisting the code around to account for all of the various internal consistencies in maven-artifact
(to give an example, between versions 3.8.6 and 3.8.7, the sort order of e.g. 0.x
vs 0-x
swapped). By going with the simpler model, there are vastly fewer bugs that need to be worked around, which means a greater likelihood that the sorting rule ends up being useful.
Hey,
I tried to use
smallrye-common-version
for our release scripts and things went wrong because3.6.0.CR1
is considered newer than3.6.0
.I switched back to using Maven Artifact as these two versions are sorted properly with
ComparableVersion
.The algorithm in
MavenVersionScheme
is not exactly trivial so I will refrain from breaking things :)./cc @dmlloyd