[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] version numbers and release qualifiers
|
I think you misunderstand the version ordering. The version
comparison tool gives this:
$ java -jar maven/lib/maven-artifact-3.3.3.jar 3.0 3.0-RC1
Display parameters as parsed by Maven (in canonical form) and
comparison result:
1. 3.0 == 3
3.0 > 3.0-RC1
2. 3.0-RC1 == 3-rc-1
3.0 is clearly greater than 3.0-RCx, for all numeric values of "x".
Emily Jiang wrote on 1/19/20 12:03 PM:
I do see one problem with this version
comparison.
If we do a release for CDI 3.0, we will
release 3.0-M1, 3.0-M2,..., then we do 3.0-RC1, 3.0-RCx, finally
release 3.0.
However, 3.0<3.0-Mx<3.0-RCx. If we try
to do version range with [3.0,), we will end up with 3.0-RCx
instead of the final version, 3.0. Thought?
Emily
Werner wrote:
> If you take the example of the JSR 385 API
> https://mvnrepository.com/artifact/javax.measure/unit-api
> shows correctly, that the most recent version is "2.0".
I see versions as introduced to take the time part (_the most recent_)
out of equation.
Rules described in "Version Order Specification", when followed result in:
> $java -jar maven-artifact-3.6.3.jar 2.0 2.0-EDR
> Display parameters as parsed by Maven (in canonical form) and comparison result:
> 1. 2.0 == 2
> 2.0 < 2.0-EDR
> 2. 2.0-EDR == 2-edr
It doesn't matter that 2.0 is "the most recent" as time is not
considered, (if not explicitly embedded in version). You decided for
EDR/PRD qualifiers, and they are treated in that way.
> Even the detail view at Sonatype https://search.maven.org/artifact/javax.measure/unit-api
> Shows the order correctly, but if you see another view
> https://search.maven.org/search?q=javax.measure
>
> it makes the wrong statement, that "2.0-PRD" was the latest version
> and you also end up with that using certain build tools that try to guess the "latest" version.
Because _it is_ per rules of Version Order Specification:
> $ java -jar maven-artifact-3.6.3.jar 2.0-PRD 2.0-EDR 2.0
> Display parameters as parsed by Maven (in canonical form) and comparison result:
> 1. 2.0-PRD == 2-prd
> 2.0-PRD > 2.0-EDR
> 2. 2.0-EDR == 2-edr
> 2.0-EDR > 2.0
> 3. 2.0 == 2
It's treated as version 2.0-even-later-than-service pack (special
token "sp" I guess).
If JSR 385 API is not happy with the maven-way - I'm pretty sure its
Release Notes/SCM Plan are clear about version order and
(non-standard) qualifiers used. As version scheme used works against
maven rules, the responsibility of choosing the correct version is
delegated to client (taken out of tools using VOS Rules).
> In my experience at least this Mavencentral bug also assumes that "x.y-rc02" < "x.y-rc1" or similar with "b1" vs. "b01" etc.
Bug, as reported one? Can you share the ticket number? Or example.
Because current maven does not assume that:
> $ java -jar /usr/local/maven/lib/maven-artifact-3.6.3.jar x.y-rc02 x.y-rc1
> Display parameters as parsed by Maven (in canonical form) and comparison result:
> 1. x.y-rc02 == x.y-rc-2
> x.y-rc02 > x.y-rc1
> 2. x.y-rc1 == x.y-rc-1
or
> $ java -jar maven-artifact-3.6.3.jar b01 b1 b00001
> Display parameters as parsed by Maven (in canonical form) and comparison result:
> 1. b01 == beta-1
> b01 == b1
> 2. b1 == beta-1
> b1 == b00001
> 3. b00001 == beta-1
--
Piotrek
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
