Feature: Supported boolean flag in API

[adriens]

❔ About

Is your feature request related to a problem? Please describe.

Actually, /api/postgresql.json :

[
  {
    "cycle": "15",
    "eol": "2027-11-11",
    "latest": "15.1",
    "latestReleaseDate": "2022-11-07",
    "releaseDate": "2022-10-10",
    "lts": false
  },
  {
    "cycle": "14",
    "eol": "2026-09-30",
    "latest": "14.6",
    "latestReleaseDate": "2022-11-07",
    "releaseDate": "2021-09-27",
    "lts": false
  },
  {
    "cycle": "13",
    "eol": "2025-11-13",
    "latest": "13.9",
    "latestReleaseDate": "2022-11-07",
    "releaseDate": "2020-09-21",
    "lts": false
  },
  {
    "cycle": "12",
    "eol": "2024-11-14",
    "latest": "12.13",
    "latestReleaseDate": "2022-11-07",
    "releaseDate": "2019-09-30",
    "lts": false
  },
  {
    "cycle": "11",
    "eol": "2023-11-09",
    "latest": "11.18",
    "latestReleaseDate": "2022-11-07",
    "releaseDate": "2018-10-15",
    "lts": false
  },
  {
    "cycle": "10",
    "eol": "2022-11-10",
    "latest": "10.23",
    "latestReleaseDate": "2022-11-07",
    "releaseDate": "2017-10-02",
    "lts": false
  },
...
]

does not give as much information as the official page, especially the Supported boolean column :

💡 The solution you'd like

I would like to get a ready to use boolean attribute that would tell me is the version is supported or not... I mean without any client side computation.

Alternatives you've considered

• Client side compuation

[captn3m0]

I think such a flag might make sense for actual versions (15.1, 14.5), but not for release cycles - this is what the badge API will do, and we can perhaps expand it from there.

The long-planned supported-versions field in the planned spec for releases.json fulfills a similar purpose - make it easy to check whether the version you're running is supported or not.

However, given that most clients will need to do some more computation to check for support, this isn't necessarily a good idea. (postgres 10 is still supported under Ubuntu 18.04 for eg), so clients are expected to do more work.

Could you provide some details as to why your client is so constrained?

[adriens]

this is what the badge API will do, and we can perhaps expand it from there.

⚡

The long-planned supported-versions field in the endoflife-date/releases.json#1 fulfills a similar purpose - make it easy to check whether the version you're running is supported or not.

Great news 👏

Hmmm, here is the context :

✔️ We run psql on rhel
✔️ I strongly rely on psql Versioning policies for our maintenance process : therefore I need a matching (so I don't have to explain...tec...)

Could you provide some details as to why your client is so constrained?

☝️ The main concern for me would to not have to make additional compuatations : I guess

💭 Hopefully it did answer your questions @captn3m0 🤞

[captn3m0]

Most clients will anyway have to check:

1. What version of RHEL are you running
2. What is the latest version of postgres for that release of RHEL
3. In specific cases, lookup RedHat ELS lists to check if the package is included (https://access.redhat.com/articles/4997301)
4. If you are running the latest version as per RedHat
5. Grab the release cycle from the API
6. Check the latest version and match it. This is unlikely to match, because RHEL doesn't really track latest. RHEL 7 still has 9.2.24 for eg.
7. Finally, check the EOL date for the release cycle and see if it is crossed.

If you want to rely on just the postgres versioning policy, then you should just match the version, and the eol date.

[captn3m0]

Going to close this, will create a separate issue for listing supported versions in the API.

[adriens]

Sure, thanks a lot 🙏