Add Adoptium Version Number to JSON Meta data and include it in Zip and MSI (All?) installers

Unfortunately, jdk8u302-b08.1 MSI-re-spin, it's release file contains no information about being 8.0.302+8.1. This causes an infinite update loop ( as API contains this information). Is there any way to prevent this?
JAVA_VERSION="1.8.0_302"
OS_NAME="Windows"
OS_VERSION="5.2"
OS_ARCH="amd64"
SOURCE=" .:OpenJDK: 63197bc5b8:"
IMPLEMENTOR="Eclipse Foundation"
BUILD_SOURCE="git:2349d4e"
BUILD_SOURCE_REPO="https://github.com/adoptium/temurin-build.git"
SOURCE_REPO="https://github.com/adoptium/jdk8u.git"
FULL_VERSION="1.8.0_302-b08"
SEMANTIC_VERSION="8.0.302+8"
BUILD_INFO="OS: Windows Server 2012 R2 Version: 6.3"
JVM_VARIANT="Hotspot"
JVM_VERSION="25.302-b08"
IMAGE_TYPE="JDK"
Ideally, there should be either a SEMANTIC_VERSION="8.0.302+8.1" or something like ADOPTIUM_VERSION="8.0.302+8.1" (if you prefer to keep SEMANTIC_VERSION strict to the standards). (edited)
16h
gdams:microsoft: @tushev can you provide more context here? What is causing an infinite loop? What API? Thanks
16h
tushev @gdams I'm using https://api.adoptium.net/v3/assets/latest/8/hotspot and it provides me with
"version": {
"adopt_build_number": 1,
"build": 8,
"major": 8,
"minor": 0,
"openjdk_version": "1.8.0_302-b08",
"security": 302,
"semver": "8.0.302+8"
}
which my updater translates to 8.0.302+8.1. Then it parses local C:\Program Files\Eclipse Foundation\jdk-8.0.302.8-hotspot\release (provided above) and gets 8.0.302+8.0, which results in 8.0.302+8.0 < 8.0.302+8.1. In that case, the updater suggests downloading the new MSI again and again.
16h
tushev I understand that this is peculiarity of my updater, but we either use adopt_build_number for comparing versions (so we need it on both sides, local release and the API), or we lose the possibility to notify users of releases that differ only in adopt_build_number
15h
gdams:microsoft: Ahh I see, so the tool has no way of identifying the version of the local binary when it’s a rebuild. Can you not leave a file in the JDK directory that correctly identify the version number from the API. The challenge we have is the concept of OpenJDK version numbers vs our build numbers
15h
gdams:microsoft: Presumably the shasum is of no use to you either? Trying to work out if you could check against that
15h
johno my position would be that the semver is wrong
15h
johno the semver should be 8.0.302+8.1
15h
tushev
Can you not leave a file in the JDK directory that correctly identify the version number from the API.
Well, that may solve the MSI case, however, if the user unzips the directory directly or just installs the MSI outside of my updater, it won't work:(
Ideally, there should be another reliable field, like STRUCTURED_VERSION="8.0.302+8.1" or ADOPTIUM_VERSION="8.0.302+8.1" (edited)
15h
tushev Well, my tool would pick semver =8.0.302+8.1 automatically.
15h
johno @tushev you mean if semver = 8.0.302+8.1 then everything would work correctly for you?
15h
johno tempted to put something into the api to detect semvers it disagrees with and alert on it
15h
tushev @johno Yes, either SEMANTIC_VERSION = "8.0.302+8.1" or JAVA_VERSION = "8.0.302+8.1" in release file
I'm also in the process of preparing the new release, so if there would be another field, I'm willing and ready to add another regex:) (edited)
15h
johno well, my preference would be since imo "semver": "8.0.302+8" is incorrect fix that inside https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u302-b08.1/OpenJDK8U-jdk_x64_windows_hotspot_8u302b08.msi.json (edited)
15h
tushev To me, the API is OK, the problem is with release file
15h
tushev I can reliably get 8.0.302+8.1 from API:
"version": {
"minor": 0,
"patch": null,
"msi_product_version": "8.0.302.8",
"security": 302,
"pre": null,
"adopt_build_number": 1,
"major": 8,
"version": "1.8.0_302-b08",
"semver": "8.0.302+8",
"build": 8,
"opt": null
},
But all I can get from release file on the drive, is 8.0.302+8.0 (edited)
15h
tushev P.S. Just checked release files from 8.0.302+8 and 8.0.302+8.1 - they are completely identical...
1h
martijnverburg:microsoft: We could patch that json manually and then make sure we have it say .2 for the next MSI respin (which is likely to happen as there’s a CurrentVersion Registry key bug)
1h
gdams:microsoft: It’s not the JSON that needs patching. It’s the actual release file in the binary unfortunately
:+1:
1

39m
martijnverburg:microsoft: Is that in the MSI binary or the actual OpenJDK binary?
36m
gdams:microsoft: It’s the openjdk binary so that needs rebuilding, and then a TCK and then the MSI needs rebuilding. it’s a lot of work considering sometimes we release a second release because of a packaging issue
34m
martijnverburg:microsoft: @tushev - Instead on relying on that release file is it possible to rely on the json meta data file instead?
29m
gdams:microsoft: Unfortunately not, that’s the point (once the binary is on the local system) the updater cannot tell. That’s why I suggested looking at the shasum
23m
tushev @martijnverburg I need something that is present locally, and both in MSI-installed and unZIPped distributions. It can be a JSON, a release file or whatever - but it has to be present locally, so my updater would pick an existing distribution and compare it to the API.
Isn't it possible to add an extra line like ADOPTIUM_VERSION="8.0.302+8.1" during release process so it would not require re-building?
20m
tushev @gdams Unfortunately, even if I would cache the SHAs (which may not be very reliable), for 8.0.302+8.1 and 8.0.302+8 SHAsums are completely identical...
16m
martijnverburg:microsoft: Ok then I think our meta data Json file is the right way to handle this going forwards. Hmmmm perhaps for max accuracy we need to separate the installer version from the binary version?
8m
tushev I can modify my updater so it will parse JSONs as well, however, that JSON should be included in both MSIs and ZIPs. Is it possible?

Start by examining the release file and the referenced MSI JSON metadata, then trace how the MSI and ZIP installers package local metadata. Define a metadata value that distinguishes the installer rebuild and ensure it is present in both distributions, with the local value matching the API version information.

Written by the indexing model from the issue text.