-
-
Notifications
You must be signed in to change notification settings - Fork 766
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Generate Visual Timeline #285
base: master
Are you sure you want to change the base?
Conversation
9403711
to
6f9f706
Compare
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:
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:
https://nodejs.org/en/about/releases/ uses:
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:
|
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?
Some do have newer versions at the bottom: |
Ordering is currently based on the sequence in the markdown file. I plan to take |
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. 👍 |
d2c9ffc
to
53cae1b
Compare
@captn3m0 what is the result of this PR ? is there any improvements ?
] |
Planning to pick this (and the dependabot automation bits) for my hacktoberfest. |
53cae1b
to
b97b6ee
Compare
9c22583
to
9bc6b9a
Compare
- Adds better start/end date calculations - Try to guess the life of a release - If that fails, provide overrides in front-matter - Label any guesses specifically
Don't see a way to fix, so will probably just disable timeline for that page. |
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:
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 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. |
Sure, I just mentioned Google Chart to not forget about it should we need another solution.
I also tried Mermaid with endoflife.date data but was not convinced by the result.
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. |
Initial work to solve for #166.
The code is based on https://github.com/nodejs/lts-schedule with some changes:
TODO:
using theas per conventionsortReleasesBy
configurationPreviews are functional: https://deploy-preview-285--endoflife-date.netlify.app/centos, though I've enabled it only if we didn't already have an image configured.