| Message ID | 20250915-fix-switchers-js-v1-2-523ef53fe802@bootlin.com |
|---|---|
| State | New |
| Headers | show |
| Series | doc: fix the switchers menu | expand |
Hi Antonin, On 9/15/25 2:19 PM, Antonin Godard via lists.yoctoproject.org wrote: > The Autobuilder can also give this information from the run-docs-build > script. Fallback on "dev" if we can't find the information, so we can > still build. > How about following the exact same mechanism as on yocto-docs? Read this info from poky.yaml file which is automatically generated by set_versions.py? Cheers, Quentin
On Mon Sep 15, 2025 at 3:24 PM CEST, Quentin Schulz via lists.openembedded.org wrote: > Hi Antonin, > > On 9/15/25 2:19 PM, Antonin Godard via lists.yoctoproject.org wrote: >> The Autobuilder can also give this information from the run-docs-build >> script. Fallback on "dev" if we can't find the information, so we can >> still build. >> > > How about following the exact same mechanism as on yocto-docs? > > Read this info from poky.yaml file which is automatically generated by > set_versions.py? The idea was to maintain the active releases in one location (yocto-docs), thus the idea behind this variable. This information is stored here: https://git.yoctoproject.org/yocto-docs/tree/documentation/set_versions.py#n29 How would having an auto-generated poky.yaml.in file fit into that? I can generate a poky.yaml from set_versions.py here using BITBAKE_CURRENT_RELEASE, but I don't see any advantages to it - unless I'm misunderstanding. Thanks, Antonin
Hi Antonin, On 9/15/25 3:57 PM, Antonin Godard wrote: > On Mon Sep 15, 2025 at 3:24 PM CEST, Quentin Schulz via lists.openembedded.org wrote: >> Hi Antonin, >> >> On 9/15/25 2:19 PM, Antonin Godard via lists.yoctoproject.org wrote: >>> The Autobuilder can also give this information from the run-docs-build >>> script. Fallback on "dev" if we can't find the information, so we can >>> still build. >>> >> >> How about following the exact same mechanism as on yocto-docs? >> >> Read this info from poky.yaml file which is automatically generated by >> set_versions.py? > > The idea was to maintain the active releases in one location (yocto-docs), thus Having a OE component depend on a YP component isn't usually the things are done in both projects though, rather the opposite. Add a comment in yocto-docs's set_versions.py that one needs to update BitBake's as well? I'm not sure having to patch BitBake docs once every 6 months requires to add such dependency between both projects? If set_versions.py are close enough in their git context, you could even send the patch to both mailing list and apply the same patch in both repos at the same time (though I just realized writing this that maintainers of BB aren't the same as YP-docs :) ). > the idea behind this variable. This information is stored here: > > https://git.yoctoproject.org/yocto-docs/tree/documentation/set_versions.py#n29 > > How would having an auto-generated poky.yaml.in file fit into that? I can > generate a poky.yaml from set_versions.py here using BITBAKE_CURRENT_RELEASE, > but I don't see any advantages to it - unless I'm misunderstanding. > I would avoid the need for BITBAKE_CURRENT_RELEASE environment variable which is currently set from set_versions.py from YP-docs. I guess it could be acceptable if somehow the build system of BitBake docs provides this info? Cheers, Quentin
On Mon Sep 15, 2025 at 4:19 PM CEST, Quentin Schulz wrote: > Hi Antonin, > > On 9/15/25 3:57 PM, Antonin Godard wrote: >> On Mon Sep 15, 2025 at 3:24 PM CEST, Quentin Schulz via lists.openembedded.org wrote: >>> Hi Antonin, >>> >>> On 9/15/25 2:19 PM, Antonin Godard via lists.yoctoproject.org wrote: >>>> The Autobuilder can also give this information from the run-docs-build >>>> script. Fallback on "dev" if we can't find the information, so we can >>>> still build. >>>> >>> >>> How about following the exact same mechanism as on yocto-docs? >>> >>> Read this info from poky.yaml file which is automatically generated by >>> set_versions.py? >> >> The idea was to maintain the active releases in one location (yocto-docs), thus > > Having a OE component depend on a YP component isn't usually the things > are done in both projects though, rather the opposite. I see. We do explicitely state the compatible YP version in doc/releases.rst, so I didn't think this could be a problem. [...] > I would avoid the need for BITBAKE_CURRENT_RELEASE environment variable > which is currently set from set_versions.py from YP-docs. I guess it > could be acceptable if somehow the build system of BitBake docs provides > this info? I'm thinking this whole switcher implementation should be revised to only consider Bitbake tags and maintain the active releases here, and have YP/Bitbake docs completely independent - considering your latest comments. Antonin
On 9/15/25 4:30 PM, Antonin Godard wrote: > On Mon Sep 15, 2025 at 4:19 PM CEST, Quentin Schulz wrote: >> Hi Antonin, >> >> On 9/15/25 3:57 PM, Antonin Godard wrote: >>> On Mon Sep 15, 2025 at 3:24 PM CEST, Quentin Schulz via lists.openembedded.org wrote: >>>> Hi Antonin, >>>> >>>> On 9/15/25 2:19 PM, Antonin Godard via lists.yoctoproject.org wrote: >>>>> The Autobuilder can also give this information from the run-docs-build >>>>> script. Fallback on "dev" if we can't find the information, so we can >>>>> still build. >>>>> >>>> >>>> How about following the exact same mechanism as on yocto-docs? >>>> >>>> Read this info from poky.yaml file which is automatically generated by >>>> set_versions.py? >>> >>> The idea was to maintain the active releases in one location (yocto-docs), thus >> >> Having a OE component depend on a YP component isn't usually the things >> are done in both projects though, rather the opposite. > > I see. We do explicitely state the compatible YP version in doc/releases.rst, so > I didn't think this could be a problem. > > [...] /me shrugs I just don't like the idea of making projects even more interdependent, but I personally don't care about the relationship between OE and YP but I've heard it is very important to some. I'm not sure this would make them unhappy though. >> I would avoid the need for BITBAKE_CURRENT_RELEASE environment variable >> which is currently set from set_versions.py from YP-docs. I guess it >> could be acceptable if somehow the build system of BitBake docs provides >> this info? > > I'm thinking this whole switcher implementation should be revised to only > consider Bitbake tags and maintain the active releases here, and have YP/Bitbake > docs completely independent - considering your latest comments. > We could. The issue is that people probably aren't too familiar with which version of BitBake is for which YP release :/ We do have a page (https://wiki.yoctoproject.org/wiki/Releases) where it is mentioned though. Quentin
diff --git a/doc/conf.py b/doc/conf.py index f61241e28b..5845220f6f 100644 --- a/doc/conf.py +++ b/doc/conf.py @@ -14,12 +14,15 @@ # import sys # sys.path.insert(0, os.path.abspath('.')) +import os import sys import datetime from pathlib import Path -current_version = "dev" +# The current version of Bitbake we are building for is passed from the +# Autobuilder. +current_version = os.getenv("BITBAKE_CURRENT_VERSION", "dev") # String used in sidebar version = 'Version: ' + current_version
The Autobuilder can also give this information from the run-docs-build script. Fallback on "dev" if we can't find the information, so we can still build. Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> --- doc/conf.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)