Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V4-planning: "MSI-style" version request #2

Open
tushev opened this issue Mar 24, 2021 · 1 comment
Open

V4-planning: "MSI-style" version request #2

tushev opened this issue Mar 24, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@tushev
Copy link

tushev commented Mar 24, 2021

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

@tushev tushev added the enhancement New feature or request label Mar 24, 2021
@johnoliver
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Todo
Development

No branches or pull requests

2 participants