From: Quentin Schulz <foss+yocto@0leil.net>
To: docs@lists.yoctoproject.org,
Michael Halstead <mhalstead@linuxfoundation.org>,
YP docs mailing list <docs@lists.yoctoproject.org>
Subject: Re: [docs] Version bump before release
Date: Fri, 18 Mar 2022 07:47:22 +0100 [thread overview]
Message-ID: <14D40357-15CC-46D2-B63A-66AED89F291F@0leil.net> (raw)
In-Reply-To: <CADfgfobCTXyBYSSjekdKJp4ekrmHWH+imjpARMrCMLp2gwTr5w@mail.gmail.com>
Hi all,
On March 18, 2022 1:04:32 AM GMT+01:00, Michael Halstead <mhalstead@linuxfoundation.org> wrote:
>Hello,
>In the past we've correctly bumped the versions in the yocto-docs release
>branches before the release build and I only need to update the master
>branch to update the switcher on the website. This doesn't happen reliably
>though and we've been having to patch the build system to make the docs
>build correctly.
>
>Ideally all that would be needed at release time is a patch like
>https://git.yoctoproject.org/yocto-docs/commit/?id=78545b8f42657c21bc3cac96429d3950b07a3aca
>to update the website.
>
For the new releases (not the dot releases), it is essential this patch is merged with correct infos before tagging, specifically the poky.yaml file.
For dot releases, what matters is the bump of the dot release in poky.yaml, the rest of the changes aren't that important because it's impossible to always keep it up-to-date.
releases.rst and switchers.js are taken from master for all builds anyways by yocto-autobuilder-help so we don't technically have to worry about those making it before tagging day. Those need to make it to the master branch as soon as possible though (basically after tagging).
Two changes to conf.py need to be done too for releases. current_version needs to be bumped and bitbake_version to be set.
>Lately I've also had to make patches like these as well during release:
>
>https://git.yoctoproject.org/yocto-autobuilder-helper/commit/?id=ca8e95276d96b94d97e269b0f4f9ad306f8417d7
>https://git.yoctoproject.org/yocto-docs/commit/?h=honister&id=7980cfe942a1c8ceb3fd6b003ec6346d9bc11015
>(honister branch)
>
What is REALLY important is to get the current_version and bitbake_version correct in conf.py. poky.yaml changes might be required too but I haven't checked yet.
>What process can we put in place to make sure these version bumps happen on
>the named branch before the release candidate builds?
>
>Richard suggested a test that would make RC builds fail if the docs version
>were outdated. Any idea how to write that test?
Check the content of conf.py that current_version is NOT dev and that bitbake_version is set. Not sure how to detect a pre-release not having the current_version bumped though.
If current_version is set, extract it and make sure it's used in poky.yaml.
Cheers,
Quentin
> What other ideas come
>to mind?
>
>Thank you,
next prev parent reply other threads:[~2022-03-18 6:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-18 0:04 Version bump before release Michael Halstead
2022-03-18 0:32 ` [docs] " Steve Sakoman
2022-03-18 5:01 ` Lee, Chee Yang
2022-03-18 6:47 ` Quentin Schulz [this message]
2022-03-18 10:05 ` Michael Opdenacker
2022-03-18 11:16 ` Quentin Schulz
2022-03-18 11:32 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14D40357-15CC-46D2-B63A-66AED89F291F@0leil.net \
--to=foss+yocto@0leil.net \
--cc=docs@lists.yoctoproject.org \
--cc=mhalstead@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox