Re: [docs] [PATCH v2 1/3] tools/fetch-releases-json: add to fetch and format releases.json

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Antonin,

On 3/3/26 2:14 PM, Antonin Godard wrote:
> Hi,
> 
> On Fri Feb 27, 2026 at 11:26 AM CET, Quentin Schulz via lists.yoctoproject.org wrote:
>> Hi Antonin,
>>
>> On 2/26/26 3:00 PM, Antonin Godard via lists.yoctoproject.org wrote:
>>> Add a simple script that can be used to fetch and format the
>>> releases.json file from https://dashboard.yoctoproject.org/releases.json.
>>>
>>
>> OK but why do we want this in the tree? It'll still be regularly outdated.
>>
>> I understand not wanting to rely on a network connection, but we already
>> need that for the bitbake's object.inv we download... so this ain't that
>> much different.
> 
> You're right, I forgot about that inventory file :( made this change with an
> offline build in mind.
> 
> Fetching the file when building seems like a proper solution, although:
> 
> - IMO, we need to fallback on fixed values, even if they're outdated, to not
>    block a documentation build if we can't fetch the releases.json file
> 

Makes sense. I actually thought about this a few days ago and I was 
wondering if we shouldn't simply have a single version as fallback... 
The current one. There's no reason to show multiple versions in the 
switcher (and elsewhere?) when there's only one built locally?

So maybe still generate the file from git and not even attempt to 
download releases.json?

> - on the Autobuilder, we need to do the opposite: block a build if we can't
>    fetch the releases.json file
> 
> - avoid fetching the file again if we already did (especially important on the
>    Autobuilder as we don't want the file to be fetched for every tag + we don't
>    want it to change during a build)
> 

Wondering if we can't simply handle releases.json downloading 
externally. I think we should still have whatever handles releases.json 
in the git repo(s) (but maybe not?) but we can simply put releases.json 
somewhere the script in the repo expects one to be present.

Essentially... if there's a releases.json available at location X, you 
use it, if not, then you use the fallback of the current version. The 
git repo wouldn't have a releases.json, only the autobuilder downloads 
it once before building all docs.

I guess the main issue is that we wouldn't know whether the current 
version is EoL if you don't download releases.json? Is it important? 
(thinking about people building the docs locally such that their 
colleagues only look at the documentation for the version they actually 
use).

What do you think?

Cheers,
Quentin