I recently did a rant on twitter[0] on how release/download pages of various languages/tools get it wrong, especially with respect to giving EoL Dates/policy and a list of supported releases.
This is my attempt at solving the problem. If you have to every check the EoL date of anything, or if you have to verify that the version you have is supported, just visit endoflife.date/toolname.
The website runs on Netlify, and is built with Jekyll. All the data is stored as Front Matter in Jekyll itself. Contributions are welcome on GitHub to add more languages/tools etc.
Digression alert. I've been thinking of a multi-OS package analysis database that I wish existed. The idea being, a database of information on packages to answer questions like:
- Which packages of what OSes include the file path /usr/share/whatever/some/file.name?
- Which packages of what OSes include the file with this hash, and where does it install?
- On what date was this revision of that file included in this package?
And so on. This idea doesn't quite fit in to that model, but it is along the lines I'm thinking - that conveniently organized metadata across distros could be very useful in a number of ways. In particular, I've had each of those questions above; they can be surprisingly time consuming to answer. More generally, there's interesting research to do there with security implications, and I suspect there's interesting stuff to do with it that I haven't thought of yet.
There are a lot of fuzzy edges. One big one is managing different aspects of "sameness" for a file in different contexts that makes sense. You mentioned the problems with binary hashes; there are others, like comments in scripts and config files. If distro-X just spams boilerplate at the top of the config file, is that the "same" file? What if they add or rewrite informational comments in a config file?
I think the answer is that sometimes they are; it depends on the question.
I also noticed that it is really easy to end up wanting to pull data from source repos and bug trackers, but down that path lies madness.
Anyway, I don't have any plans to start building this. But it is an interesting project to think through.
This looks pretty useful to me. It would be cool if it were possible to sign up for an account which would let you created "projects" which consist of a list of the tools that you are using for a given project. Extra cool if you could input the version you are currently using, and get it to alert you if you are getting close to EOL.
If I add Fedora, Ruby, and a few other things will you accept the PR (assuming it's good of course. I just don't want to waste my time if you are already happy with the current list and don't want any more)?
It'd still be nice to not have this tied to hover, relative dates are more useful to get a gist of how long you've got - those absolute dates are usually what you need to sell it to management.
As far as I know, no browser actually does anything special with `<time>` elements. Might be nice for screenreaders though, so I'll see if I can switch.
I don’t know if this has been done but I suppose a good use of the `<time>` element would be for browser addons to target it and use the `datetime` attribute for something like “add to calendar (ical)” or “translate the text content to my locale” or something similar.
It's an annoying UX antipattern. It doesn't work on mobile, and forces one to use the mouse instead of just seeing the information in its more useful form.
If anything, why not put the "N days from now" text in the title attr instead?
Not every pattern that is controversial is an anti-pattern. Relative time is useful for a different reason than absolute time. One use case is not worse than the other, they're just different.
Hey, this seems like a pretty useful website, one quick comment is that it does not seem to be easily usable by colorblind people. Almost 10% of males are red-green colorblind, so while normal people can quickly scan through the lists using color, colorblind people have to manually read each 'Ends in ...' or 'Ended ...'.
Not a huge issue in this case since generally you would lookup your product on the left side of the table and then look at a single cell on the right side, but it can't hurt to switch to an alternative color scheme - blue + olivegreen is one that I've seen pretty often.
Using some sort of patterned background as well as color would help. diagonal lines, zigzag lines, etc, like some patterns at https://www.transparenttextures.com
Potentially a very useful convenience. A couple of suggestions:
1. I would make it a bit more obvious when versions are not yet released. For instance nodejs v14 is listed with its planned support lifetime in the same colours as v12. While there is an indication that this is not a current release (no content in the release column for that row), it might be useful to also alter the colouring (perhaps fade or grey it out a bit?).
1.1. Or instead perhaps leave out unreleased versions for consistency (you don't list Debian 10 for instance, though there is some info out there: expected release mid 2019, expected mainstream support to mid 2022, expected LTS (server only) to mid 2024: https://en.wikipedia.org/wiki/Debian_version_history#Release...
1.2: Or perhaps list future releases in a second table?
2. A couple of things that might be useful to add if you have time to add and maintain the info: MS SQL Server versions & their service packs and Firefox ESR versions.
3. A display bug: at any window size in current Chrome on Windows with default zoom, "Fedora Linux" wraps in a way that suggests "Linux" is a separate item in the list. Perhaps use a non-breaking space to help that?
I don’t use RHEL so I wasn’t sure what to include and what to exclude. (And the Release Policy is like 5 pages long). So I just left the image without the versions being covered.
Now that I now, will give it a shot. Can I reach out to you for a review once the PR is up?
Probably doesn't matter, but with rhel eol is virtually nonexistent, you put enough money in their face and they will support you forever. We have a few machines running very old rhel versions because we put enough money in front of them and they couldn't say no.
Really great idea, thank you! I can't believe I hadn't thought of this before.
It would be awesome to have a simple API as well that can be curl'ed from a script. I think we could possibly make it work with the current Jekyll base by just rendering JSON in addition to HTML. I'm willing to give it a shot if that's something people would like (unless someone else wants to).
The Ubuntu page is a little confusing. The "security support" on that page appears to be "Extended Security Maintenance" which is available for kernel security updates, and only if you have a subscription to the Ubuntu Advantage.
Agreed, for most users there's effectively no ongoing support for 14.04, which makes the way it appears in this table highly misleading. Based on this I wouldn't recommend this list.
For this kind of situation I would suggest marking the item in red with a footnote indicating that some limited support is still available.
To the CSS class 'page-link' to prevent the situation where a link is broken on a space, allowing it to simultaneously be at both the end of one line, and at the start of the next.
That might be because everything isn't one line for myself. It's a bit of a hack, because HTML usually thinks it's fine to break a text cell on a space, and this prevents it.
There's probably better solutions, like maybe converting spaces in title links to nbsp.
It was just a quick hack that seemed to work for me. I obviously didn't test it on bigger screens. Whoops.
I repeatedly google this stuff en mass and thought a community-managed website would be a really great so thank you for saving me loads of effort! I'll be PR-ing a bunch of stuff to help out ;)
It may be worth adding a per-version EOL cell, and potential caveats. Windows operating systems, for example, can receive paid support if you happen to have a billion dollars laying around.
Edit: By per-version EOL cell, I mean to allow URL references on a per-version basis for websites that don't list them all on one page, or at all. While there a date-released may also be super useful in some situations when you're trying to figure out how long since it's been patched.
My pet peeve is Python specifically. They have a PEP per release which basically tells you what all will become EOL on this release, which is very confusing.
And they also list unsupported releases on the main download page.
Can you clarify on the “release cell” part? Not sure what you mean by that.
I get you on the Windows part. It took me quite some time to figure out what all is even possible. The Windows page definitely needs a disclaimer.
Is this information manually maintained? It might honestly be nicer to see if you can locate the primary source for these projects and just iframe in that authoritative document to avoid running the risk of being out of date.
The metadata isn’t hard to maintain (only the Latest Release field changes often). And I made this because the authoritative source are very often confusing with no clear dates.
PHP supported release page is great for eg, but Python is a mess.
As a dev working primarily in PHP I hear all you're saying, but am mostly just enjoying the PHP > Python moment ;P
That's good to hear, as I sort of said, my primary concern for EOLs is that they have been known to change over time and when they do I'd like to be sure the source I'm relying on is tracking those changes.
Big fan of this, excellent idea. EOL is always non-trivial to find for each project.
I think a good addition could be a feed of some sort available for each project e.g. https://endoflife.date/ruby/feed. You could then poll that from readers or Slack integrations and be notified when particular projects have entered EOL. Maybe an early warning for could be useful too, 3 months before EOL or something like that?
It's a shame, BDNA's Technopedia used to have an excellent, free online search engine that could be leveraged to search EOL information.
For context, Technopedia is a library that, for a yearly subscription, could supplement detailed supplier End of Life/Support/Extended details onto your CMDB/Asset Management System. It was a godsend when dealing with large software audits.
Flexera have since acquired BDNA, and from the looks of things, the public access to the system has been locked out: https://portal.technopedia.com/landing
Might be worth checking out for those who are in large orgs and have to deal with this problem en mass.
That is what I used as reference. Note how the table differentiates between Security and EOL but doesn’t provide dates for the first, since they are dependent on future releases.
Nice concept. As a suggestion, I think a single page with #bookmarks would be more easily read than individual pages selected from the menu bar. But I’d be curious to hear the pros of the current design choice.
This is my attempt at solving the problem. If you have to every check the EoL date of anything, or if you have to verify that the version you have is supported, just visit endoflife.date/toolname.
The website runs on Netlify, and is built with Jekyll. All the data is stored as Front Matter in Jekyll itself. Contributions are welcome on GitHub to add more languages/tools etc.
[0]: https://twitter.com/captn3m0/status/1110504412064239617