Do we need to track current release versions?

[hugovk]

An idea to hugely reduce the maintenance burden would be to skip the "current release" column.

There are 76 products (and growing!), each with I guess 3 or more current versions, that's like over 230 current version numbers to keep updated!

Software released every day, even with automation to create PRs that's a lot of PRs coming in.

The mission of this site is very clearly about end of life dates, no mention of current releases in the README:

Keep track of various End of Life dates and support lifecycles for various products. Visit endoflife.date for a list of supported products. This information is very often hard to track or badly presented. This project collates this data and presents it in an easily accessible format, with URLs that are easy to guess and remember.

or at https://endoflife.date/.

For example, if I want to know when the EOL of Ruby 2.6 is, I'm not really worried that 2.6.8 is the latest patch version. Or if I want to know when RHEL 7 reaches EOL, I don't need to know 7.9 is the current minor.

Thoughts?

[usta]

I give my 2 cents about dropping information about "latest" tag so we can at least keep giving information just for x.y series instead of x.y.z...

[captn3m0]

As an end-user, I want to be able to verify:

• Which versions are supported?
• Is my version supported?

(From the Guiding Principles)

Without tracking latest, we can't answer the above questions. The end result will be users having to check the upstream source, which will again vary wildly in both quality of information and how easily accessible this information is (See Unity for eg - the website doesn't have a single page listing the latest release).

The site name just happens to be the most obvious thing we track, but being helpful is my north star.

Without this information, it becomes much harder for meaningful automation to be built as well (such as checking if you're running a supported version of Rails - knowing that you are on a supported branch isn't good enough).

Still planning to get the automation changes by end of october, so hopefully the maintenance burden will reduce - idea is to still use PRs (automate but validate) for verification, but we can let it auto-merge if it feels good enough.