Add EOL-Reached field

[adoptopenjdk]

Add EOL-Reached field

[OrangeDog]

@tushev that should be [6, 7, 9, 10, 12, 13, 14] right now, or [8, 11, 15] for the inverse.

[M-Davies]

"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}

[aahlenst]

@tushev We don't have the tendency to remove things. Maybe there were no MSIs back then, at all?

[aahlenst]

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.

[johnoliver]

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}

[M-Davies]

Thanks, now got it. Well again, IMO v3/assets/latest then needs vendor...

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

[aahlenst]

@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].

[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.

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.

[M-Davies]

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}

[M-Davies]

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

[M-Davies]

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

[aahlenst]

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?).

[M-Davies]

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.

[tushev]

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.

[tushev]

Thanks, now got it. Well again, IMO v3/assets/latest then needs vendor...

[M-Davies]

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

[johnoliver]

• 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.

[tushev]

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.

[OrangeDog]

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.

[M-Davies]

I've been looking at this a little bit and here are my thoughts:

• eol_reached in /v3/info/available_releases. We make the available_releases attribute a map instead of a list (as well as the version numbers) and add the eol_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 adding eol_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 ?

[M-Davies]

@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

[OrangeDog]

As the list of EOL releases will continually grow, perhaps it should be available_supported_releases to match available_lts_releases.

[tushev]

@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

[tushev]

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).

[M-Davies]

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.

[tushev]

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.

[tushev]

Thanks!!

And how soon does usually the staging-api goes into main api?

[nickebbitt]

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

[tushev]

From my point of view, it could be on the same level as release_name, or inside version...

[M-Davies]

PR is open but in-progress while I play around with options and testing

[tushev]

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?

[M-Davies]

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)

[tushev]

@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.

[M-Davies]

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 the latest 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?

[tushev]

Well, looks good to me. Some questions:

1. 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}?
2. Is "16" : { expected_support_eol" : "2021-03-15T12:12:35Z" } expected to be changed during release lifetime?
3. 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).
4. Definitely /v3/assets/latest/{feature_version}/{jvm_impl} needs vendor.
5. 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)?

[tushev]

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?

[M-Davies]

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

[M-Davies]

Thanks, now got it. Well again, IMO v3/assets/latest then needs vendor...

This issue is blocked by #365 now then :)

[nickebbitt]

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

[M-Davies]

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 😉

[M-Davies]

#368 reverts the introductions of previous logic introduced by #353 pending investigation into adding vendor fields

[M-Davies]

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?

[tushev]

@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)

[karianna]

@M-Davies - Did you manage to get a chance to look at this before you left for your new gig? :-)

[M-Davies]

@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

[karianna]

We think this should be deferred to a Human decision. That is, API's should not dictate EOL.