Release process, script release banner, and v1.0.0 preparation - #50
Merged
Merged
Conversation
Infrabase had no version anywhere but a hardcoded "0.5.0" in the Sphinx configuration. The release is now derived from the git tag, the way SO3 derives its boot banner: - scripts/ibversion.sh prints it: `git describe --tags` of the tree the script belongs to, reduced to the base version (a tagged commit and development on top of v1.0.0 both give "1.0.0", an -rc suffix is kept), with an IB_VERSION_FALLBACK constant for a tree without git metadata. - scripts/common/banner.sh, sourced first thing by every user-facing script, prints "[infrabase v1.0.0] <script> <args>" on stderr, once per invocation: the first script to print exports IB_BANNER_SHOWN, so build.sh does not print it again through the scripts/bitbake wrapper, nor deploy.sh through tezi-feed-serve.sh. dbuild.sh forwards the flag into the container for the same reason. stderr keeps the stdout of listing commands (deploy.sh -l) clean. qemu-ifup/ifdown are left out: QEMU runs them, not the user. - doc/source/conf.py takes |version| and |release| from the same helper.
Infrabase takes SO3's branch-per-release model: main is the development line, every minor version gets a long-lived release/vX.Y maintenance branch, patch releases are tagged on it (vX.Y.Z, -rc for candidates), and each tag has a GitHub Release, exactly one marked Latest. - doc/source/release_process.rst: the procedure, adapted from SO3's. What differs is what a version means here (the build interface product trees rely on: IB_* variables, script options, layers and classes), the per-release checklist (README table, CHANGELOG, IB_VERSION_FALLBACK; no recipe pins), and the check before tagging: Infrabase has no build workflow, so the build is validated by hand in the build container on the commit being tagged. - README: a Releases section with the maintenance-branch table, 1.0 as the current stable line. - CHANGELOG: the v1.0.0 entry, which is also the GitHub Release notes. The boot-chain documentation was still describing IB_BOOT_CHAIN and IB_HYPERVISOR as two orthogonal variables, and IB_BOOT_CHAINS_SUPPORTED, all replaced by the ordered chain in #45. README, the user guide, the build-system page and a comment in local.conf now describe the ordered stages, IB_HYPERVISOR as derived, and IB_BOOT_STAGES_SUPPORTED, so the first release does not ship documentation of its predecessor.
A build of main from a fresh tree failed in usr-linux:do_configure: "Package 'libdrm' not found", from src/graphic/kmscube. The minimal buildroot configuration dropped the graphical stack on 2026-07-09 (7bce647: mesa3d, libdrm, ... removed, fbdev + evdev kept for LVGL), but ":lvgl" is on by default and still added every src/graphic demo, all of which link against libdrm (fb_benchmark gbm too, kmscube and gbmtest EGL and GLESv2 as well). Trees built before that date kept libdrm in their sysroot and never saw it, which is how the validation of the time passed. src/graphic/CMakeLists.txt now checks each dependency with pkg-config and adds a demo only when the rootfs provides what it links against, with a status message otherwise. Installation already tolerates a missing binary (usr_do_install_file_root), so nothing else changes; lvglsim is built as before. Found by the pre-release build of v1.0.0: on a fresh worktree of this branch, build.sh bsp-linux + deploy.sh bsp-linux now succeed on virt64, the demos are skipped ("graphic: no libdrm in the rootfs"), lvglsim is deployed, and the image boots to the login prompt under st.sh.
A build.sh bsp-linux + deploy.sh bsp-linux on a fresh tree left `git status` with ten untracked paths: the storage image and the U-Boot copy in filesystem/, the buildroot output links in linux/rootfs/, and the user-space sources the :lvgl patch set materialises in linux/usr/src/. Untracked build products are how SO3 ended up committing its lvgl files in v6.2.4, after which no fresh clone could build; the lvgl ones here have the same property (committed, do_patch refuses to re-create them). Anchored patterns, so nothing tracked beside them is hidden. linux/rootfs/board is a symlink, hence no trailing slash on it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings Infrabase SO3's release mechanism and prepares v1.0.0, its first release.
Release model (same as SO3).
mainis the development line. Each minor version gets a long-livedrelease/vX.Ybranch, patch releases are tagged on it (vX.Y.Z,-rcfor candidates), and every tag gets a GitHub Release, exactly one marked Latest. The procedure is indoc/source/release_process.rst, adapted from SO3's:IB_*variables, script options, layers and classes.CHANGELOG,IB_VERSION_FALLBACK; no recipe pins.Release banner. Every user-facing script now prints
[infrabase v1.0.0] <script> <args>on stderr, once per invocation:build.shdoes not print it again through thescripts/bitbakewrapper,deploy.shnot again throughtezi-feed-serve.sh, anddbuild.shnot again inside the container.scripts/ibversion.sh, SO3'sso3version.shlogic), with a fallback constant for a tree without git metadata.|release|uses the same helper, replacing the hardcoded 0.5.0.Documentation. README, the user guide and the build-system page still described
IB_BOOT_CHAIN/IB_HYPERVISORas two orthogonal variables andIB_BOOT_CHAINS_SUPPORTED, all replaced by the ordered chain in #45. They now describe the current model, so v1.0.0 does not ship its predecessor's documentation.Validation:
sphinx-build -Wbuilds clean, titled "1.0.0 documentation".st.sh -h,mount.sh -h,build.sh -l(with the bitbake wrapper),updiff.sh,tezi-feed-serve.sh --statusanddbuild.sh build.sh -l.deploy.sh -lkeeps its stdout clean.Found by the pre-release build. Following the new "check the tree before tagging" rule, this branch was built from a fresh worktree in the build container. Two defects on
mainsurfaced, both fixed here:Package 'libdrm' not found. The minimal buildroot config dropped libdrm on 2026-07-09, but:lvgl(on by default) still added thesrc/graphicDRM demos. Each demo is now built only when the rootfs has what it links against; lvglsim is unaffected..gitignore.After both fixes, on virt64:
build.sh bsp-linuxanddeploy.sh bsp-linuxsucceed from a fresh tree, the image boots to theinfrabase login:prompt underst.sh, andgit statusis clean.