On 10/21/26 6:33 AM, Jason Lingohr wrote:
> On 21/10/26 00:40, Eric Covener wrote:
>> maybe limit to a small number of recent releases? I find it a little
>> intrusive.
>> Maybe with fewer releases it we would even go a different way with the
>> presentation?
> [ ... ]
>> Nice addition, but as Reudiger said it's very subtle.
>>
>> -/-
>>
>> Longshot but could we get the release date single-sourced from somewhere?
>
> Okey dokey, another iteration done:
>
> * Severity summary: it's now on its own line directly under each release
> heading instead of tucked into the right side of the
> heading bar.
> * Release index: it's now a single line listing the 5 most recent releases
> with their month and CVE count. The full list is
> still there under a collapsed "All 43 releases" toggle, which works
> without JavaScript.
> * Release dates: these come from the CVE JSON we already have, specifically
> the "x.y.z released" timeline entry on each CVE.
> Each release shows the date most of its CVEs agree on, and the build
> prints a warning when they disagree. No new data source
> to maintain.
> * That turned up four releases whose CVE records disagree on the date. The
> page shows the majority date for these, but the JSON
> records are worth fixing:
> o 2.4.25: CVE-2020-11985 says 2020-08-07, the rest say 2016-12-20
> o 2.2.32: CVE-2016-5387 says 2016-07-18, the rest say 2017-01-13
> o 2.0.65: CVE-2011-0419 (2011-05-21) and CVE-2011-3192 (2013-07-12)
> disagree with the 2013-07-22 majority
> o 2.0.46: CVE-2003-0083 says 2004-04-02, the rest say 2003-05-28
> * Releases that were never published, or only fixed in development, show no
> date rather than a misleading one.
> * The 2.2, 2.0 and 1.3 pages get all of this as well, since they use the
> same generator.
>
>
I like this. Question: Do we publish the json files as well? If yes are these
the single files? If yes I guess a kind of index
file could be helpful. Background: While I really like the design of the new
page, but we might have consumers that are interested
in the json data for automatic processing on their side.
Regards
RĂ¼diger
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]