search

adoptium / temurin-build

Eclipse Temurin™ build scripts - common across all releases/versions
Apache License 2.0
1.02k stars 247 forks source link

Inconsistency with registry / RELEASE file and API #2248

Open tushev opened 3 years ago

tushev commented 3 years ago

Description of the inconsistency:

  1. In API, there is "semver": "11.0.9+101" 
    "version": {
  "build": 1,
  "major": 11,
  "minor": 0,
  "openjdk_version": "11.0.9.1+1",
  "patch": 1,
  "security": 9,
  "semver": "11.0.9+101"
}

At the same time, release file for that release contains

SEMANTIC_VERSION="11.0.9.1+1"

but not "semver": "11.0.9+101".

For updater, this makes comparing versions more complicated (although not impossible), as there are no two fields that can be compared directly. The updater tool has to perform computations on its own, which is better to be avoided.

This may not seem like a major issue, but it may give wrong results in some exotic cases. And yes, I can parse SEMANTIC_VERSION and then compare standalone fields, if this fails, but I it is possible that new fields may be introduced, so I prefer to give control to API (by ordering by revision/semver) rather then trying to compute something on updater's side, which, ironically, may not always be the latest available updater (not everyone updates everything regularly).

  1. For 11.0.9+11.1, the API had "semver": "11.0.9+11.1" while the corresponding release file had SEMANTIC_VERSION="11.0.9+11" and MSI version was 11.0.9.11.

Thus my updater will never be able to determine that locally installed version is "11.0.9+11.1", it will assume that the user has "11.0.9+11" and will always suggest to update until 11.0.9+12 or greater arrives. (https://github.com/AdoptOpenJDK/openjdk-support/issues/209#issuecomment-731591686)

Proposed solution

aahlenst commented 3 years ago

Semantic version can only consist of three elements (https://semver.org/spec/v2.0.0.html). Everything else is wrong.

karianna commented 3 years ago

@johnoliver thoughts on this?

johnoliver commented 3 years ago

we discussed this at length, the current (not great) solution is the best without breaking the semver spec. There are not really any good ways to represent a java version as a semver without breaking the spec in someway. A suggested alternative would be to add the point number on to the semver metadata i.e 11.0.9+1.0.1 however typically we have used the first number in the semver metadata as javas build number and the second number as our build number. Given the patch release needs to have higher priority than those 2 we would need to move it to the front changing what the first number means.

The current choice does maintain ordering as 11.0.9+11.1 < 11.0.9+101 so updates should be correct, if you wish to use the original version number then openjdk_version is available too

tushev commented 3 years ago

Maybe my initial report is a bit cumbersome :) I'd like to clarify.

I'm happy with current numbering scheme. What I'm asking about, is:

so all the three sources (API, release file and Windows registry) would be consistent - every one of them will contain both 11.0.9.1+11.1 and 11.0.9.101 formats.

The objective is to allow for my updater to read versions in similar formats, without having to figure how to compare 11.0.9.1+11.1 <?> 11.0.9.101 on updater's side.

As of (2), I assume it was a numbering issue that is solved by switching to (100*b+x)-format?