Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] version numbers and release qualifiers
Except for qualifiers "final", "ga", "release" which are equal to no qualifier. And "sp" which is later than no qualifier.
 
See https://github.com/apache/maven/blob/a6f113abced80defc4c5d0b60e2d085b8306b274/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L356-L366
--

BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx
 
 
----- Original message -----
From: "Markus KARG" <markus@xxxxxxxxxxxxxxx>
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
To: "'jakartaee-platform developer discussions'" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] version numbers and release qualifiers
Date: Tue, Jan 21, 2020 01:25
 

Simply execute that code line. It should actually say 2.0-EDR < 2.0, as ALL qualifiers ALWAYS indicate OLDER builds than non-qualified builds.

-Markus

 

Von: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von Emily Jiang
Gesendet: Dienstag, 21. Januar 2020 00:39
An: Bill Shannon
Cc: jakartaee-platform developer discussions
Betreff: Re: [jakartaee-platform-dev] version numbers and release qualifiers

 

Thanks Bill! You were right. I rechecked the versioning ordering and it does suggest 3.0>3.0-RC1.

 

I was confused by the previous statement:

> $ 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

 

should 2.0-EDR < 2.0 then?

I might have misunderstood something.

Thanks

Emily

 

On Mon, Jan 20, 2020 at 3:50 AM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

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 




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

Werner wrote:
 
> If you take the example of the JSR 385 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.
 
 
 
 
> Shows the order correctly, but if you see another view
 
 
> 
 
> 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
 
 
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
 
 

 

_______________________________________________
jakartaee-platform-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

 



--

Thanks
Emily

_______________________________________________
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
 

Back to the top