Re: [jakartaee-platform-dev] version numbers and release qualifiers

[Werner Keil <werner.keil@xxxxxxx>]

Well is this problem new?

 

As the mentioned CDI example always used certain qualifiers:

https://search.maven.org/artifact/javax.enterprise/cdi-api

 

The most JCP era CDI 2 included  "2.0", "2.0-EDR1", "2.0-PFD2", "2.0-PFD", "2.0.Beta1", "2.0.Alpha1" to 6, and "2.0.SP1".

 

Not sure, what difference the "." vs. "-" made, but unless the problem was only recently introduced, CDI "2.0" also would have been considered < "2.0-PFD2" at least until "2.0.SP1" was released over a year later?

 

Werner

 

From: Emily Jiang
Sent: Sunday, January 19, 2020 21:04
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] version numbers and release qualifiers

 

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 

On Jan 18, 2020 at 4:22 pm, <Piotr Żygieło> wrote:

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