Inconsistency with registry / RELEASE file and API

[tushev]

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).

---

2. 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. (adoptium/adoptium-support#209 (comment))

Proposed solution

• leave SEMANTIC_VERSION="11.0.9.1+1" intact in release file, but introduce one more field, something like API_SEMVERSION="11.0.9+101"
• add extra Windows Registry keys in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\AdoptOpenJDK\JRE\11.0.9.11\hotspot\MSI, such as SEMANTIC_VERSION="11.0.9.1+1" and API_SEMVERSION="11.0.9+101"

[aahlenst]

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

[karianna]

@johnoliver thoughts on this?

[johnoliver]

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]

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:

• please add some key with 11.0.9.1+11.1 format to the registry - it's missing there (only 11.0.9.101 format)
• please add 11.0.9+101 to release file - it's missing there (only 11.0.9.1+11.1 format)

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?