| Re: [jakartaee-platform-dev] version numbers and release qualifiers |
Piotr, Will only sum up a few Points as there are too many individual Points below. > 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. They are not non-standard, they follow the JCP standard convention for certain stages like EDR which most other JSRs including the likes of CDI also did. > Bug, as reported one? Can you share the ticket number? Or example. We raised at least one GitHub ticket but I can’t tell the exact repository, if you have insight into Maven or Sonatype, I’m sure you can find it if you want. It was admitted by the Web GUI team that this problem/bug exists, and they said they cannot commit on a solution. Werner Sent from Mail for Windows 10 From: Piotr Żygieło 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 |