From c4bcbbf29257d594700d5a2c2572957f463a88e0 Mon Sep 17 00:00:00 2001 From: Daniel Rossier Date: Mon, 10 Aug 2026 20:58:06 +0200 Subject: [PATCH 1/2] so3: set the fallback release version to 6.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bump it before cutting release/v6.3, as version.h asks: a build from a tree without git metadata (tarball, bitbake workdir copy) banners this constant. main was still reading 6.2.4 — the 6.2.5 resync lives on release/v6.2 only, since the after-tag propagation carries the CHANGELOG, the README table and the recipe pins but not this constant. Worth remembering when cutting the next release from main. --- so3/so3/include/version.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/so3/so3/include/version.h b/so3/so3/include/version.h index 3051eacd4..6f0ec019c 100644 --- a/so3/so3/include/version.h +++ b/so3/so3/include/version.h @@ -35,7 +35,7 @@ * (see scripts/so3version.sh and include/generated/autoversion.h). Keep this in * sync with the current release tag as a safety net. */ -#define SO3_KERNEL_VERSION_FALLBACK "6.2.4" +#define SO3_KERNEL_VERSION_FALLBACK "6.3.0" /* Release version resolved at build time (git tag -> base version). */ #include From a30bb6ec8404feb7c1a7c916eaa292c3586baa9e Mon Sep 17 00:00:00 2001 From: Daniel Rossier Date: Mon, 10 Aug 2026 21:01:38 +0200 Subject: [PATCH 2/2] doc: say when the version fallback has to be bumped The propagate checklist already lists SO3_KERNEL_VERSION_FALLBACK, but the constant matters twice: in the release commit set, so the tagged tree banners the right version, and again on main, so the next release does not start a version behind. main sat at 6.2.4 while release/v6.2 was at 6.2.5 because only the second half was obvious. --- doc/source/release_process.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/doc/source/release_process.rst b/doc/source/release_process.rst index acf289290..1f520d515 100644 --- a/doc/source/release_process.rst +++ b/doc/source/release_process.rst @@ -162,6 +162,13 @@ could build. ``build (virt32)`` and ``build (virt64)`` are required status checks on ``main`` for the same reason: merging on red stays possible for a maintainer, but never by accident. +Check ``SO3_KERNEL_VERSION_FALLBACK`` too: it must already read the version +being tagged, since the tagged tree is what a gitless build banners. It +appears twice in this page on purpose — bump it **in the release commit set** +so the tag is right, and again when propagating to ``main`` so the next +release does not start a version behind (``main`` sat at ``6.2.4`` while +``release/v6.2`` was at ``6.2.5``). + Rules of thumb **************