Hide very old releases by default #50
Comments
|
I was going to add older Debian and Ubuntu releases as well, is it worth waiting on something happening with this before I do? Since I have my own uses for this API-wise (see the discussion on the FreeBSD releases request) I'm fine with adding them for my own purposes and keeping a separate branch, but it'd be better otherwise. I'd offer to do this myself but my JS skills are not up to doing so quickly. |
|
Do file the PRs, if they're too much - we can always wait on merging them (and you keep them on your local branch). I'll try to prioritize this issue meanwhile. |
|
If you'd like to work on this:
And finally, we have a very helpful guide for new contributors during Hacktoberfest as well. |
captn3m0
added
the
Hacktoberfest
|
A good inspiration is the haproxy website:
|
|
Tried out a few approaches on how to configure this, the one that seems to work best would be:
The "top n" is defined as per the sorting order (as defined by the
I tried a few other approaches that let us configure which releases to show/hide on a per-product basis, but it seems to be adding too much complexity for too little benefit. |
|
Nice work @captn3m0 👍 Details and the screenshot look very good for me. I would go with your current version and don't add more options for the moment. |
|
I prefer an approach where unsupported release is hidden and there is a checkbox at the top a user can uncheck to show. However this behavior should be able to be controlled by a flag like we can already decide if to show eol and support columns. |
|
It would be useful to have an optional URL query parameter, such as For example: https://endoflife.date/cakephp => old releases hidden by default These could be used to link to an ever automatically up-to-date list of recent or old of releaeses for a given product, depending on the need. |
This field indicates whether a release cycle is still maintained, meaning at least one of the active support / eol / discontinued / extended support dates is in the future (or is true). This new field was primarily declared to help implementing #50, but could be used elsewhere. For example, making it available in the API would make API usage simpler, because clients would not have to implement any logic to know whether a given release cycle is still maintained.
Hide oldest unmaintained release cycles by default, letting the users display them if necessary. In this version, a cycle can be hidden only if: - it is not the first cycle, - it is unmaintained (see set_is_maintained below), - the previous cycle is still maintained, - all next cycles are unmaintained. This approach allows reducing the number of releases displayed on most pages, without concealing too much information. This is also the first try at hiding releases: more approach has been discussed on #50, and we may want to test them in the future.
|
I gave it a shot on #2594. I read all you said, but I took another approach : I only hid all but the most recent unmaintained version at the bottom of the table. I find it interesting:
I think this works well in most situation, by hiding a lot of releases without concealing too much information. What do you think of this approach ? |
This field indicates whether a release cycle is still maintained, meaning at least one of the active support / eol / discontinued / extended support dates is in the future (or is true). This new field was primarily declared to help implementing #50, but could be used elsewhere. For example, making it available in the API would make API usage simpler, because clients would not have to implement any logic to know whether a given release cycle is still maintained.
This implementation hides only a single run of rows, at the very end, if they are all unmaintained. The criteria picked here for hiding unmaintained releases is one which is simple enough to understand and gives the least surprise to users (the table only gets appended, no new rows show up in the middle). Release cycles are also only hidden if there is at least 6 release cycles in total, with at least 3 of of them that can be hidden. There is no need to hide anything if the table is small or if the number of hidden releases is too low. This implementation works great for most of the current products, but may be useless for products where there are old maintained release cycles (such as Microsoft products or Ubuntu). A button has been used instead of a link because to improve accessibility (https://www.a11y-101.com/design/button-vs-link). See #50 if you want to know more about the reason why this solution was implemented.
This implementation hides only a single run of rows, at the very end, if they are all unmaintained. The criteria picked here for hiding unmaintained releases is one which is simple enough to understand and gives the least surprise to users (the table only gets appended, no new rows show up in the middle). Release cycles are also only hidden if there is at least 6 release cycles in total, with at least 3 of of them that can be hidden. There is no need to hide anything if the table is small or if the number of hidden releases is too low. This implementation works great for most of the current products, but may be useless for products where there are old maintained release cycles (such as Microsoft products or Ubuntu). A button has been used instead of a link because to improve accessibility (https://www.a11y-101.com/design/button-vs-link). See #50 if you want to know more about the reason why this solution was implemented.
This field indicates whether a release cycle is still maintained, meaning at least one of the active support / eol / discontinued / extended support dates is in the future (or is true). This new field was primarily declared to help implementing #50, but could be used elsewhere. For example, making it available in the API would make API usage simpler, because clients would not have to implement any logic to know whether a given release cycle is still maintained.
This implementation hides only a single run of rows, at the very end, if they are all unmaintained. The criteria picked here for hiding unmaintained releases is one which is simple enough to understand and gives the least surprise to users (the table only gets appended, no new rows show up in the middle). Release cycles are also only hidden if there is at least 6 release cycles in total, with at least 3 of of them that can be hidden. There is no need to hide anything if the table is small or if the number of hidden releases is too low. This implementation works great for most of the current products, but may be useless for products where there are old maintained release cycles (such as Microsoft products or Ubuntu). A button has been used instead of a link because to improve accessibility (https://www.a11y-101.com/design/button-vs-link). See #50 if you want to know more about the reason why this solution was implemented.
|
Reopening, a first implementation was done in #2594 but :
|
|
I am also wondering if the old releases should not be visible by default and hidden using JavaScript when the page is loaded. Currently users using a browser with JavaScript disabled cannot see older releases. |
I don't know if it makes things more accessible, but at least people that disabled JavaScript on their browser can now see all release cycles. A small glitch can sometime be observed on page load (for example on API Platform page) but that's not systematic and I didn't consider that to be an issue.
I don't know if it makes things more accessible, but at least people that disabled JavaScript on their browser can now see all release cycles. A small glitch can sometime be observed on page load (for example on API Platform page) but that's not systematic and I didn't consider that to be an issue.
|
Since we hide old releases fairly well now, closing this. |
Previous discussion:#41 (comment)
Write a bit of JS to hide any releases that have a end-of-life date more than 5 years in the past by default. Add a new button on the site that can be used to "show old releases".
The text was updated successfully, but these errors were encountered: