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

[karianna]

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?

[karianna]

Perhaps we can write a special Eclipse Temurin registry key here when the installer runs and updaters look at that.

[tushev]

This should work well for MSIs, but, unfortunately, I'm afraid that the issue would remain for ZIP-extracted installations...

[tushev]

@karianna any updates? :)

Again now, with both 21.0.1+12.1 and 17.0.9+9.1, there's no way to tell on the local (installed) side, what version is it. The updater gets stuck in update loop.

I would like to have that JSON file alongside with RELEASE file in JDK/JRE root installation.

Then, I would be able to reliably know what version is installed, both for MSI and ZIP packages:

    "version": {
        "minor": 0,
        "patch": null,
        "msi_product_version": "17.0.9.9",
        "security": 9,
        "pre": null,
        "adopt_build_number": 1,
        "major": 17,
        "version": "17.0.9+9",
        "semver": "17.0.9+9.1",
        "build": 9,
        "opt": null
    },

All I have now is RELEASE file:

IMPLEMENTOR="Eclipse Adoptium"
IMPLEMENTOR_VERSION="Temurin-17.0.9+9"
JAVA_RUNTIME_VERSION="17.0.9+9"
JAVA_VERSION="17.0.9"
JAVA_VERSION_DATE="2023-10-17"
LIBC="default"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.incubator.foreign jdk.incubator.vector jdk.internal.le jdk.internal.opt jdk.internal.vm.ci jdk.internal.vm.compiler jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.nio.mapmode jdk.random jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Windows"
SOURCE=".:git:a4bbf40198b1"
BUILD_SOURCE="git:16ac032d56eb0820393ca7752c13a4bab98eaf92"
BUILD_SOURCE_REPO="https://github.com/adoptium/temurin-build.git"
SOURCE_REPO="https://github.com/adoptium/jdk17u.git"
FULL_VERSION="17.0.9+9"
SEMANTIC_VERSION="17.0.9+9"
BUILD_INFO="OS: Windows Server 2022 Version: 10.0"
JVM_VARIANT="Hotspot"
JVM_VERSION="17.0.9+9"
IMAGE_TYPE="JRE"

[karianna]

No update sorry, I think this is a bug that should be fixed though!