[Feature] Generate Visual Timeline - #285

Need opinion on how to handle differing color meanings:

We currently use Green/Red/Orange to denote any dates (in the table) as being "Safe/Danger/Warning". So if an EoL date is within a few months, it changes color to Orange.

However, now we have 2 bars for "active/security" support of every release cycle. Currently, I'm using green/orange, but it needs to be shown better. Perhaps different shades of green?

This is current:

Something like this perhaps?

Tried to keep the shades far apart for accessibility, and it seems to work? (Tested here)

You should probably match the colors with what's in the table. This is difficult right now because the "security-only" etc are not color coded (apparently it's colored by how far away it is?) but having two separate views on the same info with different coloring is awkward I must say.

Matching is difficult, but you're right - it is awkward if they do not match. I do have some ideas:

• splitting the green in table to match the dual green above for one). So the 2 shades of green mean exactly the same thing
• Similarly using 2 shades of red for Active/Security support in the table and above. This might make reading the chart harder though?

The yellow we use is difficult since it only shows up around the today line. Maybe we could do this on hover (green changes to yelow if date is approaching soon)?

Will post some options here.

https://www.php.net/supported-versions.php uses:

• red: EOL
• orange: security only
• green: active support

https://nodejs.org/en/about/releases/ uses:

• orange: unstable
• grey: maintenance
• blue: active
• green: current

https://python-release-cycle.glitch.me/ (and its derivatives https://jefftriplett.com/django-release-cycle/ and https://hugovk.github.io/drupal-release-cycle/) is similar to PHP and uses:

• red: dead/EOL
• orange: security
• green: bugfix
• blue: prerelease

Oh and in general, the charts in this PR are looking good!

I noticed some have newer versions at the top, can they be re-ordered so newer versions are at the bottom, like the other websites tend to have?

• https://deploy-preview-285--endoflife-date.netlify.app/bootstrap
• https://deploy-preview-285--endoflife-date.netlify.app/python

Some do have newer versions at the bottom:

• https://deploy-preview-285--endoflife-date.netlify.app/centos

Ordering is currently based on the sequence in the markdown file. I plan to take sortReleasesBy into account so it's consistent with the tables below.

Need suggestions on how to showcase releases that are currently supported, but end dates are not currently known. I had two ideas:

For products where we know approximate release dates (such as Fedora, where releases will likely last for 13 months) - perhaps we could put a date for eol, but mark it as "approximate: true" and that gets a special shading in the timeline.

Another would be to keep it automatically extended to the next month (or 3 months) with the same shading and text stating: "EoL dates are not known in advance".

The first impression is really good, you are on the right direction. 👍
I'll do a full review when you have completed all points in the TODO list. Let me know...

@captn3m0 what is the result of this PR ? is there any improvements ?
If this one not done yet , we could add this project/idea to Hacktoberfest ideas.
[ Another thing (not related to this PR : The links about ideas in Hacktoberfest part is not working in :

Click through the following issues to read more.
    Autofocus to search input
    Hide old releases by default
    Add Product Logo in the sidebar

]

Planning to pick this (and the dependabot automation bits) for my hacktoberfest.

WIP Release Image samples

Easier to browse everything in a single place. This comment hotlinks to the deploy website, so will hopefully auto-update on future builds.

Great progress!

Some are a bit packed, this is the most extreme :)

Don't see a way to fix, so will probably just disable timeline for that page.

Some of products names are cropped :

Would love to see this feature on endoflife.date.

An alternative solution that may be lighter to implement would be to use https://developers.google.com/chart/interactive/docs/gallery/timeline#an-advanced-example. I think it's lighter because:

• it does not require to generate images using a python script during the build,
• it's just templating.

But it has one drawback : it is not allowed per the Google agreements to embed it. This mean we would have to use the version hosted on Google CDNs (=> privacy concerns).

Let me rework this PR, and I can attempt a variant with Google Charts as well. I don't want to link to Google Charts if at all possible, so maybe we can do offline builds using it instead.

We now have one for Python at https://devguide.python.org/versions/

We started off using Mermaid.js to create one like this: python/devguide#988

At build time we generated a Mermaid .mmd file, and the site loaded the JS which then read the mmd data and rendered it as an SVG.

We've since updated it to generate the SVG directly, using templating, at build time: python/devguide#1034

This means we don't need to load a large JavaScript library, the SVG is available immediately, and the SVG is more responsive.

Let me rework this PR, and I can attempt a variant with Google Charts as well. I don't want to link to Google Charts if at all possible, so maybe we can do offline builds using it instead.

Sure, I just mentioned Google Chart to not forget about it should we need another solution.

We started off using Mermaid.js to create one like this: python/devguide#988

I also tried Mermaid with endoflife.date data but was not convinced by the result.

We've since updated it to generate the SVG directly, using templating, at build time: python/devguide#1034

It is a better alternative than Google Charts, even if it may be more difficult to implement at first, IMHO. Not sure it is that simple, but we could port the template to liquid.