RFC: Supported Versions GitHub Action

[captn3m0]

A common usecase for our API seems to be:

1. Fetch the list of supported versions from our API.
2. Then run your CI workflow using a matrix against the supported versions.

However, there's a bunch of complications that you need to deal with to go from an API call to (1):

1. Decide on which level of support you want. Typically this is "release cycle is not yet EOL", but it could also be "release cycle is not EOL, and release cycle is LTS", or some other similar combination.
2. Parse accordingly, taking care of dates in the past or the future across all the fields.

I wrote up a simple README + spec (action.yml) for a github action that would easily support this usecase: https://github.com/endoflife-date/supported-versions

Feedback is welcome for the same. Will get to writing the code after this is finalized. The general idea is:

1. Let the user provide a list of filters (EOL/Active Support/Extended Support/LTS)
2. Return data that matches these filters (applied together as an AND operation)
3. Additionally return some helpful values, such as the complete metadata, and a list of filtered cycles.

There's example input/outputs in the README.

I will be hanging out today in the Gitter chat in case you'd like to discuss this faster. Replies here are fine as well.

[hugovk]

There does appear to be a need: I've seen an existing action for Python versions, so you can by default test on the currently supported 3.7-3.11. I can't seem to find it now but will keep an eye out!

Edit: now I remember, I had found it via the first link you shared :)

https://github.com/snok/latest-python-versions

[marcwrobel]

We could provide more information in the API v1 to make it easier to answer those questions :

• product-data-enricher.rb already enrich all cycles with an is_maintained field. It's only used to hide oldest release cycles for the time being, but could be added to the API v1.
• I was thinking of splitting eol / support / extendedSupport / discontinued fields to two fields : a date field and a boolean field. For example, if eol is a date, the API would return eol: <date> and is_eol: <boolean>.

[captn3m0]

I was also thinking of a splitting idea. Helps 2 ways:

1. Make it easier for API consumers to filter results. A simple jq filter will do the trick quite easily for vast majority of usecases.
2. Better type guarantees for languages that need them.

[adriens]

That's very cool to think about API consumers 💯 🙏 😗

[captn3m0]

Someone already felt this pain of dates not being easy to filter, and wrote up a jq solution that works for nodejs: https://michaelheap.com/jq-select-date-before-today/. (It doesn't work for all products, because it doesn't take bool fields into account.)

[marcwrobel]

It has a drawback though : a boolean field that would be computed from a date will be wrong over time, because it is the result of a computation that involves the current time (=> the build time). For example, a field is_eol derived from eol would be computed with is_eol = (now > eol).

This is basically the same issue there is already on the website regarding colors (green / yellow / red), but it may be more impactful.

To minimize that downside maybe we should force the site to regenerate every day at 00:00 (beware of the timezone).

[captn3m0]

That's a good point. Daily builds sound like an easy fix though.

[JLLeitschuh]

I've authored such a GitHub action here: #2786