Release process, script release banner, and v1.0.0 preparation

.gitignore

@@ -28,6 +28,23 @@ build/cache
 # below keeps untracked — a rule there would never leave this machine.
 /filesystem/boot.conf
 
+# What a build and a deploy produce, anchored so that nothing tracked beside
+# them is hidden: the storage image and the boot-chain artefacts deploy.sh
+# writes into filesystem/, the buildroot output and the links to it under
+# linux/rootfs/, and the user-space sources the :lvgl patch set materialises
+# in linux/usr/src/ (the patch set is the source; these are regenerated and
+# would make do_patch refuse to re-create them once committed).
+/filesystem/sdcard.img.*
+/filesystem/work
+/filesystem/*.bin
+/filesystem/flash0.img
+/linux/rootfs/Makefile
+/linux/rootfs/board
+/linux/rootfs/fs
+/linux/rootfs/staging
+/linux/usr/src/graphic/
+/linux/usr/src/lvgl/
+
 # TEZI HTTP feed published by deploy.sh, plus the feed server's pid/log, and
 # the makeusr.sh local deploy. Deliberately outside build/tmp so a clean does
 # not wipe a feed a board may be installing from.

CHANGELOG

@@ -0,0 +1,37 @@
+
+v1.0.0 (26 sep 2026)
+
+First release of Infrabase, and the first line with a release branch
+(release/v1.0). It is the build system the SO3, EDGE-M1, MICOFE and course
+trees are aligned on, as it stood once that alignment was done.
+
+	•	A minimal Linux system built with BitBake: U-Boot, the kernel, a
+		buildroot root filesystem and the user-space applications, for QEMU
+		virt64 and virt32, the Raspberry Pi 4 (64 and 32-bit), the Toradex
+		Verdin iMX8M Plus and x86 QEMU. Components are fetched from upstream
+		and patched from tracked patch sets; the attach guard refuses to
+		overwrite local edits, and updiff folds them back into the set.
+
+	•	The boot chain is one ordered value, IB_BOOT_CHAIN, over the stages
+		atf, optee, uboot, avz and mcuboot: Linux on a bare U-Boot, with ATF,
+		with an OP-TEE secure world, or as a guest of the AVZ hypervisor at
+		EL2. The order is checked, everything else (IB_HYPERVISOR, the stage
+		flags, the ITS) is derived from it, and each platform declares the
+		stages it can run, so an impossible combination is refused at parse
+		time.
+
+	•	Deployment to an SD-card image, a real device or a Toradex Easy
+		Installer network feed served from the tree. The deploy writes
+		filesystem/boot.conf, and st.sh starts QEMU from it. On virt64 U-Boot
+		can be read off the card by the QEMU boot ROM
+		(IB_FIRST_STAGE_FROM_CARD). The user space goes where the running
+		root is: into the ramfs, or onto the rootfs partition.
+
+	•	A containerised build environment (dbuild.sh): the cross toolchains and
+		every host package in one image, the tree bind-mounted, the build run
+		as the calling user.
+
+	•	Every script prints the release it belongs to when it starts,
+		"[infrabase v1.0.0] build.sh bsp-linux", from the git tag
+		(scripts/ibversion.sh); the documentation derives its version from the
+		same helper.

README.md

@@ -6,9 +6,8 @@ filesystem and user-space applications — for real boards and for QEMU-emulated
 ones, and deploys it to an SD-card image or to a real device.
 
 It builds four components — **ATF**, **OP-TEE**, **AVZ** and **Linux** — and
-lets you combine them freely: Linux standalone or as a guest of the AVZ
-hypervisor, on a firmware chain with or without ATF and with or without a
-secure world. See [What gets built](#what-gets-built) below.
+lets you combine them: Linux standalone or as a guest of the AVZ hypervisor,
+on a firmware chain with or without ATF and with or without a secure world. See [What gets built](#what-gets-built) below.
 
 It is driven by [BitBake](https://docs.yoctoproject.org/bitbake), the task
 orchestrator behind Yocto, but stays deliberately small: components are fetched
@@ -65,31 +64,29 @@ The platform is selected with `IB_PLATFORM` in `build/conf/local.conf`:
 
 ## What gets built
 
-Two independent variables in `build/conf/local.conf` decide which of the four
-components end up in an image:
+One variable in `build/conf/local.conf`, **`IB_BOOT_CHAIN`**, decides which of
+the four components end up in an image: the stages that run before Linux, in the
+order they run, joined by `+` — `atf`, `optee`, `uboot`, `avz`, `mcuboot`. So
+`uboot` is Linux on a bare U-Boot, `atf+optee+uboot` adds a secure world,
+`uboot+avz` runs Linux as a guest of the AVZ hypervisor, and
+`atf+optee+uboot+avz` has both. Everything else (`IB_HYPERVISOR`, the ITS, which
+recipes are built) is derived from it, and the order is checked.
 
-- **`IB_BOOT_CHAIN`** — the firmware underneath the OS: `uboot`, `atf+uboot`,
-  or `atf+optee+uboot` (a secure world).
-- **`IB_HYPERVISOR`** — what the firmware hands control to: `none` (Linux runs
-  directly) or `avz` (AVZ at EL2, Linux as its guest).
+What each platform can run is a set of stages (`IB_BOOT_STAGES_SUPPORTED`):
 
-They are orthogonal: AVZ boots on a bare U-Boot chain just as well as on a full
-secure one. Every combination a platform supports is buildable:
-
-| Platform | `uboot` | `atf+uboot` | `atf+optee+uboot` |
-|---|---|---|---|
-| `virt64` | none / avz | none / avz | none / avz |
-| `verdin-imx8mp` | — | none / avz | none / avz |
-| `rpi4_64` | none / avz | none / avz | — |
-| `rpi4` | none | — | — |
-| `virt32` | none | — | — |
+| Platform | Supported stages |
+|---|---|
+| `virt64` | `atf optee uboot avz mcuboot` |
+| `verdin-imx8mp` | `atf optee uboot avz` (`atf` required) |
+| `rpi4_64` | `atf uboot avz` |
+| `rpi4`, `virt32`, `x86-qemu` | `uboot` |
 
-An absent cell is a hardware or upstream limit, not an omission — the i.MX8MP
+A missing stage is a hardware or upstream limit, not an omission — the i.MX8MP
 boot ROM always installs BL31, TF-A's `rpi4` port is AArch64-only, OP-TEE has no
 `plat-rpi4` upstream (and the BCM2711 has no secure memory controller, so a TEE
 there could never be real), and AVZ ships aarch64 defconfigs only. Each is
-explained next to `IB_BOOT_CHAINS_SUPPORTED` in `build/conf/local.conf`, and
-asking for an unsupported combination is refused at parse time rather than
+explained next to `IB_BOOT_STAGES_SUPPORTED` in `build/conf/local.conf`, and
+asking for a stage a platform cannot run is refused at parse time rather than
 producing a board that boots nothing.
 
 ## Layout
@@ -107,6 +104,33 @@ filesystem/             storage images and the mounted partitions (p1, p2)
 doc/                    this documentation (Sphinx)
 ```
 
+## Releases
+
+Infrabase uses a branch-per-release model, the same as SO3: development happens
+on `main`, and every minor version gets a long-lived `release/vX.Y` maintenance
+branch on which patch releases are tagged (`vX.Y.Z`, or `vX.Y.Z-rc` for
+candidates). Each tag has a matching
+[GitHub Release](https://github.com/smartobjectoriented/infrabase/releases).
+Every script prints the release it belongs to when it starts
+(`[infrabase v1.0.0] build.sh bsp-linux`); `scripts/ibversion.sh` prints it on
+its own.
+
+The full procedure — cutting patch and minor releases, tagging and publishing —
+is documented in
+[Release process](https://smartobjectoriented.github.io/infrabase/release_process.html).
+
+### Maintenance branches
+
+Each minor line has its own long-lived branch. Bug fixes for a published version
+land there and are tagged as patch releases.
+
+| Line | Branch | Latest release | Status |
+|------|--------|----------------|--------|
+| 1.0  | [`release/v1.0`](https://github.com/smartobjectoriented/infrabase/tree/release/v1.0) | [v1.0.0](https://github.com/smartobjectoriented/infrabase/releases/tag/v1.0.0) | Current stable |
+
+See all versions on the
+[Releases page](https://github.com/smartobjectoriented/infrabase/releases).
+
 ## Contributing
 
 Work on a branch, one topic per branch, and open a pull request; see the

build/conf/local.conf

@@ -198,7 +198,7 @@ IB_OPTEE_PLAT:virt64        = "vexpress-qemu_armv8a"
 IB_OPTEE_PLAT:verdin-imx8mp = "imx-mx8mpevk"
 # No IB_OPTEE_PLAT for rpi4_64 on purpose: OP-TEE has no plat-rpi4 upstream
 # and the BCM2711 has no secure memory controller. See
-# IB_BOOT_CHAINS_SUPPORTED above.
+# IB_BOOT_STAGES_SUPPORTED above.
 
 # virt64: SPD=opteed only on a chain that carries OP-TEE (BL2 then loads
 # BL32 = OP-TEE from the FIP). Without it the FIP carries BL31+U-Boot only —

build/meta-usr/recipes-usr/lvgl/files/0001-usr-linux-1.0-r0/0002-CMakeLists.txt.patch

@@ -1,9 +1,30 @@
 --- /home/rossierd/soo/infrabase/build/tmp/work/usr-linux-1.0-r0/usr-linux-1.0/src/graphic/CMakeLists.txt	1970-01-01 01:00:00.000000000 +0100
 +++ ./src/graphic/CMakeLists.txt	2025-08-28 13:15:04.926201072 +0200
-@@ -0,0 +1,6 @@
+@@ -0,0 +1,27 @@
 +
-+add_subdirectory(drm_tool)
-+add_subdirectory(drm-utils)
-+add_subdirectory(kmscube)
-+add_subdirectory(gbmtest)
-+add_subdirectory(fb_benchmark)
++# DRM/KMS and GL demos. Every one of them needs libdrm, fb_benchmark gbm too,
++# and kmscube and gbmtest EGL and GLESv2 on top — none of which the minimal
++# buildroot configuration ships (it keeps fbdev + evdev for LVGL). Build each
++# one only when the rootfs provides what it links against, instead of failing
++# the whole user-space configure on a fresh tree.
++
++find_package(PkgConfig REQUIRED)
++pkg_check_modules(IB_GRAPHIC_DRM QUIET libdrm)
++pkg_check_modules(IB_GRAPHIC_GBM QUIET gbm)
++pkg_check_modules(IB_GRAPHIC_GL QUIET egl glesv2)
++
++if(IB_GRAPHIC_DRM_FOUND)
++	add_subdirectory(drm_tool)
++	add_subdirectory(drm-utils)
++else()
++	message(STATUS "graphic: no libdrm in the rootfs, skipping the DRM demos")
++endif()
++
++if(IB_GRAPHIC_DRM_FOUND AND IB_GRAPHIC_GBM_FOUND)
++	add_subdirectory(fb_benchmark)
++
++	if(IB_GRAPHIC_GL_FOUND)
++		add_subdirectory(kmscube)
++		add_subdirectory(gbmtest)
++	endif()
++endif()

doc/source/build_system/build_system.rst

@@ -122,7 +122,8 @@ invocation, so adding a layer is a one-line change there rather than a hand edit
        ``avz`` recipe, not the SO3 kernel.
 
 Which of ``atf``, ``optee`` and ``avz`` a given build actually compiles is decided
-by ``IB_BOOT_CHAIN`` / ``IB_HYPERVISOR`` at the dependency level (``bsp.bbclass``),
+by ``IB_BOOT_CHAIN`` at the dependency level (``bsp.bbclass``, through the
+``IB_CHAIN_HAS_<STAGE>`` flags derived from it),
 not by adding and removing layers — the layer set is the same for every build.
 
 Let's focus on the **meta-linux** layer as an example.

doc/source/conf.py

@@ -12,6 +12,7 @@
 # serve to show the default.
 
 import os
+import subprocess
 import sys
 import sphinx
 sys.path.insert(0, os.path.abspath('.'))
@@ -69,11 +70,28 @@
 # |version| and |release|, also used in various other places throughout the
 # built documents.
 #
-# The short X.Y version.
-version = u'0.5'
+# It is derived from the git release tag by the very same helper the scripts'
+# release banner uses (scripts/ibversion.sh), so the documentation never has
+# to be bumped by hand at release time. The helper falls back to its
+# IB_VERSION_FALLBACK constant when the tree carries no git tag — which is the
+# case for the shallow CI checkout that publishes these pages.
+
+def _ib_version():
+    helper = os.path.abspath(os.path.join(os.path.dirname(__file__), '..', '..', 'scripts', 'ibversion.sh'))
+
+    try:
+        out = subprocess.check_output(['sh', helper], universal_newlines=True)
+    except (OSError, subprocess.CalledProcessError):
+        return 'unknown'
+
+    return out.strip() or 'unknown'
+
 
 # The full version, including alpha/beta/rc tags.
-release = u'0.5.0'
+release = _ib_version()
+
+# The short X.Y version.
+version = '.'.join(release.split('.')[:2])
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

doc/source/index.rst

@@ -18,6 +18,7 @@
    dev_flow
    base_extension/base_extension
    Coding conventions <coding_conventions>
+   Release process <release_process>
    glossary
 
 |
@@ -43,6 +44,7 @@ Coding conventions and development flow
 
 - :ref:`Our coding conventions <coding_conventions>`
 - :ref:`Our development flow <dev_flow>`
+- :ref:`Release process <release_process>`
 
 
 To edit the documentation and to use the correct underlying policy, you can read `this documentation style guide <https://documentation-style-guide-sphinx.readthedocs.io/en/latest/style-guide.html>`_.