V4-planning: "MSI-style" version request

[tushev]

Hello,

Currently V3 API provides versioning according to JEP 322 (like aa.bb.cc.dd+ee.ff).
My updater sometimes encounters situations when only "MSI" style of version is available for local installations (like AA.BB.CC.DD).

If possible, I would like to have both version styles available in V4 API, like:

    "version": { ... }, // the same block like in V3 assets
    "msi_version": "11.0.9.101", // maybe for msi assets only?

so that comparison logic could be controlled from within the Adoptium project, without having to change the updater.

I believe it should be possible to extract the necessary format from MSI packages / build process somehow and make it available in the API.

Also, currently my version comparison logic is a bit tricky because it tries to take different versioning schemes and workarounds into account. Implementing this would make comparison logic much simpler, straightforward and reliable.

Related issues:
adoptium/temurin-build#2248

[johnoliver]

My learning with the mistake of using semver in the V3 API was dont try to fit a square peg in a round hole. Java uses its version scheme 322, that I think we will have to accept it as what we will use, and only what we will use. We may run into places where it does not fit our needs however I believe addressing them will probably be less of an issue than the issues we have previously encountered where a given 322 version fundamentally cannot be represented in an alternate format.

However, I would not be opposed for some sort of asset specific version in cases where Assets may be forced to represent their version in a different format specific to some ecosystem. Right now I would expect that to mostly apply to installers and platform specific binaries, I presume almost all package managers dictate some version format. In this case I would expect to add this on to an Asset and not a release, an only those assets for which this applies.

There may be practicality issues as I am not sure how we would get the version into the API. It downloading the full binary and unzipping it/extracting the version would be a HUGE bandwidth issue. However I am willing to explore how we can get that data into the API.