Comments (46)
@tushev that should be [6, 7, 9, 10, 12, 13, 14]
right now, or [8, 11, 15]
for the inverse.
from openjdk-api-v3.
"eol_reached": 0,
That would likely be "eol_reached": "false"
but yeah, that's the hope and dream :)
And, on the second thought, it may be great to have one more dedicated endpoint like v3/info/obsolete_releases
It shouldn't be too difficult and I like the idea of that. Definitely something to look into once I'm done with /v3/assets/latest/{feature_version}/{jvm_impl}
from openjdk-api-v3.
@tushev We don't have the tendency to remove things. Maybe there were no MSIs back then, at all?
from openjdk-api-v3.
In that case, we could treat them the same as non-LTS releases but instead increase the 6 month timescale to 5 years until a define EOL is defined by oracle?
There's no single entity who defines the end of an LTS branch. 8u and 11u are maintained by Red Hat. If they say it's enough, LTS is over for us because we cannot do that ourselves. But Oracle can make the LTS end earlier by not renewing TCK licenses. Because TCK licenses are handed out on an individual basis, we could loose the ability to produce 8 long before Red Hat declares it to be dead. And Oracle who maintain their own fork aren't bound by any of that (they committed to provide 8 until 2030 or so). If we bring MTS into the mix, then the length of the support timeframe depends on how close the release is to the next LTS because support for all MTS versions ends 1 year after the next LTS release.
@nickebbitt I think the single boolean is preferable, too, but we have to keep the website in mind. As a user, wouldn't it be nice to have a small info next to each binary that says "Updates at least until H2 2023"? This is also superior to the LTS marker we currently have which isn't well understood if at all.
from openjdk-api-v3.
expected_support_eol
is mostly there just to give a heads up to users as to when it is likely to happen, tbh not a big deal, can get rid of it until someone actually requests it. Will also allow us to sidestep the issue of what date to put into the LTS eol given those are less certain. It was going to be there on the principle, its data we would be calculating anyway, may be of use, so may as well put it in, but I can also see it may also create some confusion too and also not express the nuance of the situation.
In general the preference for something like vendor_supporting
\ under_active_vendor_support
\ under_active_vendor_maintenance
etc, is because almost as soon as we put the obsolete flag into the API it to some extent became a matter of opinion what it should be as different versions are eol/obsolete to different vendors. So it is preferable to show that support is a per-vendor thing, and the above names communicate that better than terms such as obsolete
or eol
.
Am I right that in the future there could be several binary in /v3/assets/latest/{feature_version}/{jvm_impl} with different vendor (provided that you introduce vendor object)?
Unlikely as all the binaries are of the same release object, which is what holds the vendor attribute. A vendor is tied to a release not a binary
Additionally on that I would likely expect that if we do add vendor
to that specific endpoint, that it would default to adopt unless the user explicitly requested a different vendor, so that request should never return a mix of vendors. If we want an endpoint that does not default to anything specific I would make the endpoint /v3/assets/latest/{vendor}/{feature_version}/{jvm_impl}
from openjdk-api-v3.
Thanks, now got it. Well again, IMO
v3/assets/latest
then needsvendor
...This issue is blocked by #365 now then :)
#365 has been resolved so I am now going to look into picking this back up again
from openjdk-api-v3.
@M-Davies What you propose regarding /v3/info/available_releases
would be a breaking change. We should avoid that at all cost. So either we need a new key that contains the map (there's no problem wrapping numbers in a string) or we add a new key like "eol_releases": [9, 10, 12, 13, 14]
.
from openjdk-api-v3.
I strongly vote against changing to map in /v3/info/available_releases as it will break hundreds of installations of my update tool, to say nothing of the others.
No worries. We are aware that we have many tools and users out there that rely on that API. I unfortunately cannot promise that we never break the API again without increasing the version number. But that would most likely be an accident. If that happens, yell at us.
btw, what is tip version?
What's currently being developed in https://github.com/openjdk/jdk/tree/master.
I would like to have a single field that will command the updater whether it should warn the user if they are using insecure/unsupported versions. It's better to rely on a single field rather than have to perform some background computations (like take A, add B) - because my software may perform these computations, but some other implementation may not (or vice versa).
I'm a friend of moving logic into APIs so that it does not have to be replicated over and over again. I could see an endpoint like needs_update
that you could send a version number to which in turn responds with yes or no or with some elaborate message.
from openjdk-api-v3.
obsolete_releases
is now set into the master branch of v3/info/available_releases
-> https://staging-api.adoptopenjdk.net/v3/info/available_releases.
Reopening to address adding obsolete_release
(or alternative name) to /v3/assets/latest/{feature_version}/{jvm_impl}
from openjdk-api-v3.
A typical binary in https://api.adoptopenjdk.net/v3/assets/latest/8/hotspot currently looks like this:
{
"binary": {
"architecture": "x32",
"download_count": 20046,
"heap_size": "normal",
"image_type": "jdk",
"installer": {
"checksum": "1fd7ccc6f444a8770cb90a4e98e51b6f0c3b22daee1b47d3ae6db25341b8fad5",
"checksum_link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u282-b08/OpenJDK8U-jdk_x86-32_windows_hotspot_8u282b08.msi.sha256.txt",
"download_count": 18954,
"link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u282-b08/OpenJDK8U-jdk_x86-32_windows_hotspot_8u282b08.msi",
"metadata_link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u282-b08/OpenJDK8U-jdk_x86-32_windows_hotspot_8u282b08.msi.json",
"name": "OpenJDK8U-jdk_x86-32_windows_hotspot_8u282b08.msi",
"size": 89952256
},
"jvm_impl": "hotspot",
"os": "windows",
"package": {
"checksum": "4c4516d3d58023b091d487f9d596101f809fd84781c6a20bdc4e013e0f13cd04",
"checksum_link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u282-b08/OpenJDK8U-jdk_x86-32_windows_hotspot_8u282b08.zip.sha256.txt",
"download_count": 1092,
"link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u282-b08/OpenJDK8U-jdk_x86-32_windows_hotspot_8u282b08.zip",
"metadata_link": "https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u282-b08/OpenJDK8U-jdk_x86-32_windows_hotspot_8u282b08.zip.json",
"name": "OpenJDK8U-jdk_x86-32_windows_hotspot_8u282b08.zip",
"size": 104939136
},
"project": "jdk",
"scm_ref": "jdk8u282-b08",
"updated_at": "2021-01-21T16:05:55Z"
},
"release_name": "jdk8u282-b08",
"version": {
"build": 8,
"major": 8,
"minor": 0,
"openjdk_version": "1.8.0_282-b08",
"security": 282,
"semver": "8.0.282+8"
}
},
// more binary objects.......
I'm trying to decide on where this theoretical obsolete
field is best placed. At the moment, I want to try and get it in the same way as release_name
. Outside the binary
block. I'll see how well that turns out
from openjdk-api-v3.
Yup. Creating an account is free and is where most of the discussion and meeting notes are produced so it's a good platform to be on anyway
from openjdk-api-v3.
LTS (long term support) Releases will never be declared obsolete as it is unlikely they will expire in the lifetime of this API
I don't think this is a good assumption to make considering JDK 11 reaches its EOL in 3.5 years. The transition from 11 to 17 should happen significantly faster than 8 to 11.
Is "16" : { expected_support_eol" : "2021-03-15T12:12:35Z" } expected to be changed during release lifetime?
Has already happened for 8. Also: Oracle might decide not to renew a TCK license. In that case the EOL might suddenly be weeks away instead of years.
Not that I'm afraid of writing a couple of extra lines of code in my updater - but it's always better to keep all the business logic in one place
What about creating an endpoint that you can send a few properties (version number, OS) which then replies with "needs update" or "all good"?
I don't work enough with the API to have a solid opinion. Might make sense to ping more actual users (Gradle, JetBrains?).
from openjdk-api-v3.
What exactly is "vendor"? Is it the very same field from /v3/binary/latest/{feature_version}/{release_type}/{os}/{arch}/{image_type}/{jvm_impl}/{heap_size}/{vendor}?
According to the swagger description:
Vendor of the binary. This is the organisation that produced the binary package.
Available values : adoptopenjdk, openjdk
Default value : adoptopenjdk
From my point of view, having an extra boolean field like eol_reached: true next to expected_support_eol would be nice. Not that I'm afraid of writing a couple of extra lines of code in my updater - but it's always better to keep all the business logic in one place (to say nothing of the local time/date, which may be incorrect... Although AFAIK more or less correct time is required for establishing an HTTPS connection).
Can do!
Am I right that in the future there could be several binary in /v3/assets/latest/{feature_version}/{jvm_impl} with different vendor (provided that you introduce vendor object)?
Unlikely as all the binaries are of the same release object, which is what holds the vendor attribute. A vendor is tied to a release not a binary
I don't think this is a good assumption to make considering JDK 11 reaches its EOL in 3.5 years. The transition from 11 to 17 should happen significantly faster than 8 to 11.
In that case, we could treat them the same as non-LTS releases but instead increase the 6 month timescale to 5 years until a define EOL is defined by oracle?
What about creating an endpoint that you can send a few properties (version number, OS) which then replies with "needs update" or "all good"?
That might be more acceptable for another issue or follow up PR as this is going to be large enough of a PR to include both the features and tests.
from openjdk-api-v3.
What about creating an endpoint that you can send a few properties (version number, OS) which then replies with "needs update" or "all good"?
It's a very good idea, especially if the endpoint will take a list of installed version strings, and provide update status for all of them in one request/response. I definitely vote for it.
That said, I still would like to have eol_reached: true
in vendor_support
for other use cases.
from openjdk-api-v3.
Thanks, now got it. Well again, IMO v3/assets/latest
then needs vendor
...
from openjdk-api-v3.
Is it possible that v3/assets/latest/{version}/{variant} would be returning "vendor_supporting": false, at least for some time? Or in such case the binaries would be withdrawn immediately?
It would depend on the version and variant whether a vendor is actually supporting the version variant or not. /v3/assets/latest/{vendor}/{feature_version}/{jvm_impl}
is probably better off in a separate issue imo as I would like to get the basic functionality in first before trying to make an endpoint with my limited experience of the codebase
from openjdk-api-v3.
eol_reached
in/v3/info/available_releases
sounds like a good idea, we should do it.recommended new branch
may be a bit of an opinion and up to the user but can think about it- As for adding the version info into
/v3/assets/latest/{feature_version}/{jvm_impl}
not sure about that one, I would like to keep the purposes of these endpoints focused and clear rather than to some extent packing them with features, unfortunately the endpoint you mentioned returns an array anyway, so there is no real good place to put additional fields without an api breaking change. - My guess is while we make binaries available we will display them in the api even though they are EOL, but I wouldn't rule out those being removed from the api at some point if Adopt decided we needed to guide people away from legacy versions.
from openjdk-api-v3.
The overall idea is to make it possible for the auto-updater tool to detect that current installation is obsolete and suggest user to switch to more recent one.
The key idea about the last question is that if, say, version 8 at some time is completely withdrawn from the api, my auto-updater won't be able to determine anything about it. So I'd suggest that /v3/info/available_releases
(or some other endpoint) should keep a list of all past releases, even if binaries are withdrawn. (like "obsolete_releases": [7,8,9 ],
)
(As an offtop, but is it really worth withdrawing binaries? Generally speaking, there are some situations with legacy software that require obsolete libraries. If a machine with it crashes, you will have to get that obsolete libraries from somewhere for reinstall, and an official site is sure the best option. Sure, such legacy systems are protected by external security measures, or even work offline. Most vendors, like Microsoft, still allow to download legacy libraries, although they are hard to find. As for persuading people to upgrade, an updater should do this ;) ).
Ideally I would like to have one single endpoint for the updater app. It's absolutely not a problem for me to perform several requests, but this may be a bit slower and your API will have 2x-3x more queries per each workstation with an auto-updater installed.
from openjdk-api-v3.
The recommended version should always be the latest LTS, no?
The user can choose otherwise if they have special needs.
Or you can follow Ubuntu's default, and either go for the latest or latest LTS depending on whether the current version is LTS.
from openjdk-api-v3.
I've been looking at this a little bit and here are my thoughts:
eol_reached
in/v3/info/available_releases
. We make theavailable_releases
attribute a map instead of a list (as well as the version numbers) and add theeol_reached
as an attribute of each version number attribute:
{
"available_lts_releases": [
8,
11
],
"available_releases": {
8 : {
"eol_reached" : "false"
},
9 : {
"eol_reached" : "true"
},
10 : {
"eol_reached" : "true"
},
11 : {
"eol_reached" : "false"
},
12 : {
"eol_reached" : "true"
},
13 : {
"eol_reached" : "true"
},
14 : {
"eol_reached" : "true"
},
15 : {
"eol_reached" : "false"
}
},
"most_recent_feature_release": 15,
"most_recent_feature_version": 16,
"most_recent_lts": 11,
"tip_version": 16
}
My only concern with this, as the GitHub markdown syntax highlighting is helpfully reminding us, JSON does not allow integer values as attribute names so I would need to double check if we use JSON at all to display the API data (if it's just a Kotlin map, that should be ok as they allow integer attribute values).
eol_reached
in/v3/assets/latest/{feature_version}/{jvm_impl}
. As John said, the API returns an array which makes things tricky here. This may be better off implementing on the openjdk-build side and addingeol_reached
to the metadata over there.
We can then extract the metadata on the API side and add it to each binary. If we go with this option, we could have a "master"versions_reached_eol
file in openjdk-build that records which versions have reached their eol and pull it over here when displaying this and/v3/info/available_releases
(unless there is a public API or record or something that already does this that I don't know about?)
The alternative would be injecting such a attribute into the/v3/assets/latest/{feature_version}/{jvm_impl}
here:
[
{
-->
"binary": {
during parsing and display it that way. That seems a bit of a hacky solution though. Thoughts @nickebbitt @johnoliver ?
from openjdk-api-v3.
@M-Davies What you propose regarding
/v3/info/available_releases
would be a breaking change. We should avoid that at all cost. So either we need a new key that contains the map (there's no problem wrapping numbers in a string) or we add a new key like"eol_releases": [9, 10, 12, 13, 14]
.
I'd prefer to leave the array as untouched as possible as I'm sure there are some tools out there that would be broken if I wrapped the numbers in a string but it's one viable option. Otherwise, yeah a seperate array would also be acceptable. I'll have a play and see what I can come up with for both scenarios
from openjdk-api-v3.
As the list of EOL releases will continually grow, perhaps it should be available_supported_releases
to match available_lts_releases
.
from openjdk-api-v3.
@M-Davies @aahlenst I strongly vote against changing to map in /v3/info/available_releases
as it will break hundreds of installations of my update tool, to say nothing of the others.
Adding a new key is much better:
So I'd suggest that /v3/info/available_releases (or some other endpoint) should keep a list of all past releases, even if binaries are withdrawn. (like
"obsolete_releases": [7,8,9]
)
Please don't forget to include all releases, even ones that have their binaries withdrawn - otherwise updaters won't be able to determine whether the installed instances are up-to-date. I had issues with users of my updater where they had several-years-old AdoptOpenJDK installations...
The new question is: whether we should include very old, non-Adopt versions of Java in obsolete_releases
?
Maybe @OrangeDog 's suggestion may help with it - an updater could check whether the major version of each local installation is present in available_supported_releases
(although I'd call it maintained_releases
), and yell at user if the releases are not present in maintained list.
And yes, maintained_releases
should include all supported versions - both LTS and short-term, so that updaters should not do some background magic computations like "is this version valid or not?".
Ideally I would like to have one single endpoint for the updater app, like /v3/info/available_releases
, and lists there like:
{
"available_lts_releases": [
8,
11
],
"available_releases": [
8,
9,
10,
11,
12,
13,
14,
15
],
"obsolete_releases": [
6,
7,
9,
10,
12,
13,
14
],
"maintained_releases": [
8,
11,
15,
16 <= see comment below
],
"most_recent_feature_release": 15,
"most_recent_feature_version": 16,
"most_recent_lts": 11,
"tip_version": 16
}
Either maintained_releases
or obsolete_releases
will be definitely enough.
UPD: Updated code as suggested
from openjdk-api-v3.
btw, what is tip version? If its 'legal' (in sense of being up-to-date and secure) to use it, even for testing purposes, then maintained_releases
should include it as well.
I would like to have a single field that will command the updater whether it should warn the user if they are using insecure/unsupported versions. It's better to rely on a single field rather than have to perform some background computations (like take A
, add B
) - because my software may perform these computations, but some other implementation may not (or vice versa).
from openjdk-api-v3.
Please see the linked PR above for what I've been playing with. I'm currently running a build/updater to verify obsolete_releases
physically appears in the API v3/info/available_releases
but the tests pass and it should pull in the whole ReleaseInfo class in on the frontend anyway so I'm confident it will appear.
I have achieved this by using a JSON file in the openjdk-build repository that contains the hardcoded eol version numbers (see the PR for a link to that file). This is mutable and I would be happy to move it over to this repo if people think it would be better used here (reason being is that it would also be used on the openjdk-build side to add to the Metadata to mark future eol releases).
Unfortunately, I can't add a "eol_reached" : "true/false"
into the metadata of existing releases as that would mean building the specific ones again. Instead, I think I'll have to look into the option mentioned above about adding it into the binary map OR adding it to each individual binary details.
The alternative would be injecting such a attribute into the/v3/assets/latest/{feature_version}/{jvm_impl} here:
[
{
-->
"binary": {
during parsing and display it that way. That seems a bit of a hacky solution though.
from openjdk-api-v3.
Well, personally I'm happy with having this data at least in v3/info/available_releases
. Thanks!!
As for me, having information in /v3/assets/latest/{feature_version}/{jvm_impl}
for each item will be the most convenient solution, and as well as it will save one a request to v3/info/available_releases
on each check for updates (thus reducing check time).
OR adding it to each individual binary details.
This may not be a very elegant solution, but it will definitely work and likely will not break existing things. I vote for it.
This may look like this:
{
"binary": { ... },
"release_name": "jdk8u275-b01",
"eol_reached": 0,
"version": {
"build": 1,
"major": 8,
"minor": 0,
"openjdk_version": "1.8.0_275-b01",
"security": 275,
"semver": "8.0.275+1"
}
And it is very convenient to work with all this data.
And, on the second thought, it may be great to have one more dedicated endpoint like v3/info/obsolete_releases
(in addition to existing ones). If it's not difficult to implement it, it would be useful. However, having the data embedded in /v3/assets/latest/{feature_version}/{jvm_impl}
and/or v3/info/available_releases
is more important to me as it will greatly save updatecheck time and eliminate extra requests.
from openjdk-api-v3.
Thanks!!
And how soon does usually the staging-api goes into main api?
from openjdk-api-v3.
that's probably one for @johnoliver or @karianna to comment on
it looks like we're due a release based on the diff between master
and production
branches
production...master
side note which I'll create an issue for - it would nice to explore how we can streamline the flow if change through staging into prod so it becomes a regular event, therefore reducing risk of large change sets dropping. Ideally it would be a single button click/action from a privileged user to initiate the process to sync master
with production
and release changes to live
from openjdk-api-v3.
From my point of view, it could be on the same level as release_name
, or inside version
...
from openjdk-api-v3.
PR is open but in-progress while I play around with options and testing
from openjdk-api-v3.
BTW, is that a rule that MSI's are always being withdrawn from obsolete releases (like https://api.adoptopenjdk.net/v3/assets/latest/9/hotspot ), while ZIPs are left available?
from openjdk-api-v3.
Interesting thread here for looking into creating a "hard" obsolete schedule (FYI I didn't realise this @tushev but the staging endpoint is not set in stone so you might want to hold off on your automation tool)
from openjdk-api-v3.
@M-Davies I'm not on Slack, can I join? (UPD: just found how)
OK, I will wait. Please tell me when it will be ready-to-use.
from openjdk-api-v3.
Meeting Notes
Feedback is needed! π
An obsolete release is a release that specifically Adopt no longer supports and builds. We define this by specifying a set of conditions loosely based on the oracle JDK release roadmap:
- LTS (long term support) Releases will never be declared obsolete as it is unlikely they will expire in the lifetime of this API
- Non-LTS releases will be declared obsolete by Adopt 6 months after GA/EA release day.
To handle other vendors which may still produce releases, we will need to reevaluate the existing and planned work for this issue as below:
FOR https://api.adoptopenjdk.net/v3/info/available_releases
- Rejig the current obsolete_releases field to express which vendor is currently supporting the version (an absent version number implies the version is not supported by that vendor). E.g:
"vendor_support" : {
"adopt" : {
"8" : {
"expected_support_eol" : null
},
"11" : {
"expected_support_eol" : null
},
"16" : {
"expected_support_eol" : "2021-03-15T12:12:35Z"
}
},
"azul"
"9" : {
"expected_support_eol" : "2021-03-15T12:12:35Z"
}
}
FOR https://api.adoptopenjdk.net/v3/assets/latest/{version}/{variant} and https://api.adoptopenjdk.net/v3/assets/feature_releases/{version}/{version_type}
- Induce an extra field in the Release object that will marry up the existing
vendor
field with a boolean (vendor_supporting
) stating if the binary is currently supported and a string (vendor_expected_support_eol
) containing the expected EOL (like above). E.g:
[
{
"binaries": [ "lots and lots of binary info" ],
"download_count": 7128,
"id": "VXNlci0xMA==",
"release_link": "https://github.com/AdoptOpenJDK/openjdk8-openj9-releases/ga/tag/jdk8u162-b12_openj9-0.8.0",
"release_name": "jdk8u162-b12_openj9-0.8.0",
"release_type": "ga",
"source": {
"link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u232-b09/OpenJDK8U-sources_8u232b09.tar.gz",
"name": "OpenJDK8U-sources_8u232b09.tar.gz",
"size": 82573385
},
"timestamp": "2018-03-15T12:12:35Z",
"updated_at": "2018-03-15T12:12:35Z",
"vendor": "adoptopenjdk",
"vendor_supporting": true,
"vendor_expected_support_eol": "2021-03-15T12:12:35Z",
"version_data": {
"adopt_build_number": 0,
"build": 0,
"major": 0,
"minor": 0,
"openjdk_version": "11.0.4+10-201907081820",
"optional": "string",
"patch": 0,
"pre": "string",
"security": 0,
"semver": "11.0.0+28"
},
}
]
- Limitation - only the feature_release endpoint has the
vendor
object attached, meaning a pre-requisite of this would be to expose the vendor param to thelatest
endpoint so it can see which vendor it is.Otherwise, if people are happy with feature_release as is, we'll skip that and get right onto coding this.(See #365)
Thoughts?
from openjdk-api-v3.
Well, looks good to me. Some questions:
- What exactly is "vendor"? Is it the very same field from
/v3/binary/latest/{feature_version}/{release_type}/{os}/{arch}/{image_type}/{jvm_impl}/{heap_size}/{vendor}
? - Is
"16" : { expected_support_eol" : "2021-03-15T12:12:35Z" }
expected to be changed during release lifetime? - From my point of view, having an extra boolean field like
eol_reached: true
next toexpected_support_eol
would be nice. Not that I'm afraid of writing a couple of extra lines of code in my updater - but it's always better to keep all the business logic in one place (to say nothing of the local time/date, which may be incorrect... Although AFAIK more or less correct time is required for establishing an HTTPS connection). - Definitely
/v3/assets/latest/{feature_version}/{jvm_impl}
needsvendor
. - Am I right that in the future there could be several
binary
in/v3/assets/latest/{feature_version}/{jvm_impl}
with differentvendor
(provided that you introducevendor
object)?
from openjdk-api-v3.
Unlikely as all the binaries are of the same release object, which is what holds the vendor attribute. A vendor is tied to a release not a binary
OFFTOP: So, if we have "adopt" and "azul" vendors, how can one get /v3/assets/latest/{feature_version}/{jvm_impl}
for a release by a specific vendor?
from openjdk-api-v3.
OFFTOP: So, if we have "adopt" and "azul" vendors, how can one get /v3/assets/latest/{feature_version}/{jvm_impl} for a release by a specific vendor?
Currently you can't as per the limitation I mentioned above. You can do it with the feature_releases
endpoint however by passing in the vendor name as a parameter -> https://api.adoptopenjdk.net/v3/assets/feature_releases/8/ga?page=0&page_size=10&vendor=adoptopenjdk
from openjdk-api-v3.
Thanks, now got it. Well again, IMO
v3/assets/latest
then needsvendor
...
This issue is blocked by #365 now then :)
from openjdk-api-v3.
what's the use-case/requirment for expected_support_eol
over just the boolean eol_reached
that can be set when it becomes a fact that EOL has in fact been reached for that vendor?
expected_support_eol
feels optimistic but not certain
from openjdk-api-v3.
Additionally on that I would likely expect that if we do add vendor to that specific endpoint, that it would default to adopt unless the user explicitly requested a different vendor, so that request should never return a mix of vendors. If we want an endpoint that does not default to anything specific I would make the endpoint /v3/assets/latest/{vendor}/{feature_version}/{jvm_impl}
You might want to add that point to #365 π
from openjdk-api-v3.
#368 reverts the introductions of previous logic introduced by #353 pending investigation into adding vendor fields
from openjdk-api-v3.
Based off the previous feedback, would the following final JSON template be sufficient assuming #365 is implemented?
FOR https://api.adoptopenjdk.net/v3/info/available_releases:
"vendor_support" : {
"adopt" : [8, 11, 16],
"azul" : [9]
}
For https://api.adoptopenjdk.net/v3/assets/latest/{version}/{variant}
and https://api.adoptopenjdk.net/v3/assets/feature_releases/{version}/{version_type}
:
[
{
"binaries": [ "lots and lots of binary info" ],
"download_count": 7128,
"id": "VXNlci0xMA==",
"release_link": "https://github.com/AdoptOpenJDK/openjdk8-openj9-releases/ga/tag/jdk8u162-b12_openj9-0.8.0",
"release_name": "jdk8u162-b12_openj9-0.8.0",
"release_type": "ga",
"source": {
"link": "https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u232-b09/OpenJDK8U-sources_8u232b09.tar.gz",
"name": "OpenJDK8U-sources_8u232b09.tar.gz",
"size": 82573385
},
"timestamp": "2018-03-15T12:12:35Z",
"updated_at": "2018-03-15T12:12:35Z",
"vendor": "adoptopenjdk",
"vendor_supporting": true,
"version_data": {
"adopt_build_number": 0,
"build": 0,
"major": 0,
"minor": 0,
"openjdk_version": "11.0.4+10-201907081820",
"optional": "string",
"patch": 0,
"pre": "string",
"security": 0,
"semver": "11.0.0+28"
},
}
]
I am omitting giving an expected EOL for now and instead just focusing on if the binary is being supported or not ("vendor_supporting": false
if not) and by whom. By keeping it simple, I'm hoping this would be acceptable to just get the basic framework in place which can then be branched off upon if the initial changes fall short. Thoughts?
from openjdk-api-v3.
@M-Davies Looks good to me π, I assume that this solves the issue.
Is it possible that v3/assets/latest/{version}/{variant}
would be returning "vendor_supporting": false
, at least for some time? Or in such case the binaries would be withdrawn immediately?
I assume we are not implementing /v3/assets/latest/{vendor}/{feature_version}/{jvm_impl}
currently? (Just curious)
from openjdk-api-v3.
@M-Davies - Did you manage to get a chance to look at this before you left for your new gig? :-)
from openjdk-api-v3.
@M-Davies - Did you manage to get a chance to look at this before you left for your new gig? :-)
Sadly not. I've been meaning to take a look but I've been really busy these past few weeks. I'd say that if anyone wants to give this a crack, I can talk them through what I've done so far and my plan
from openjdk-api-v3.
We think this should be deferred to a Human decision. That is, API's should not dictate EOL.
from openjdk-api-v3.
Related Issues (20)
- Possibly(?) incorrect parsing in β/v3β/versionβ/{version} HOT 1
- Introduce one-stop-shop endpoint for updates HOT 4
- Make it possible to download Dragonwell nightly builds HOT 1
- Consider increasing max page_size > 20 HOT 12
- OpenJ9-Versions cannot be used for info URL HOT 2
- Please sign archives HOT 1
- Add Dragonwell in openjdk-api/v3/binary HOT 2
- Speed is slow when returning info from an end point HOT 2
- OutOfMemoryError on docker-compose build frontend HOT 2
- Adopt OpenJDK binaries are not available for Windows x86 arch HOT 10
- Bintray Sunset - API docker build failed 403 on nodes-0.5.0.pom HOT 3
- Remove duplication of platforms.json and variants.json HOT 1
- Website is not showing latest HotSpot nightlies for JDK16 HOT 8
- Is there a list of file types somewhere? HOT 1
- Latest 17-ea not returned by API HOT 3
- Update AdoptOpenJDK API to redirect requests for July PSU builds to Eclipse Temurin binaries at Eclipse Adoptium HOT 1
- Wrong checksum for IBM Semeru JDK version 8u302b08 on macOS HOT 1
- p
- LTS list does not include Java 17
- "NOTICE" links on https://api.adoptopenjdk.net/q/swagger-ui/ broken HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openjdk-api-v3.