| name | update-unit |
| description | This skill should be used when the user asks to "update a unit", "bump a unit", "upgrade a unit", "update to latest version", "/update-unit", or mentions that a unit needs a version bump. Bumps a unit to the latest upstream version with a test build.
|
Update a Unit
Bump an existing unit to the latest upstream release. Updates the version, tag,
and sha256 (if applicable), checks for patch conflicts or dependency changes,
and verifies with a test build.
Workflow
Step 1: Read the Current Unit
Find and read the unit's .star file:
Glob: modules/**/units/**/<name>.star
Note the current version, source URL, tag format, and any patches.
Step 2: Find the Latest Version
Determine the latest stable release from the upstream source:
- GitHub repos — check releases/tags via the GitHub API or web
- Tarball sources — check the project's download page
Identify the new version number and the corresponding tag name. Match the
existing tag format (e.g., if current is V_9_9_P1, the new tag should follow
the same convention like V_9_9_P2).
Step 3: Research Changes
Check how other distributions have handled the version bump. This helps identify
new dependencies, removed features, or required patch updates:
- Alpine Linux — check if their APKBUILD has been updated for the new
version, and note any new
makedepends or configure flag changes
- Yocto/OpenEmbedded — check if the OE-Core unit has been updated, noting
any new patches or dependency changes
- Buildroot — check for configure flag or dependency changes
Also review the upstream changelog/release notes for breaking changes, new
dependencies, or removed features that might affect the build.
Step 4: Update the Unit
Modify the .star file:
- Update
version to the new version string
- Update
tag to match the new release tag
- Update
sha256 if the unit uses tarball sources
- Adjust
deps or configure_args if the new version requires changes
Step 5: Check Patches
If the unit has patches, verify they still apply to the new version. Check
build/<distro>/<unit>/src/ after source preparation for .rej files (the
build tree is segmented by distro — build/alpine/..., build/debian/... — and
<unit> carries its arch suffix). If patches conflict:
- Determine if the patch is still needed (the fix may be upstream now)
- If still needed, regenerate the patch against the new version
- If obsolete, remove it from the patches list
Step 6: Test Build
Build the updated unit:
yoe build --clean <unit-name>
Use --clean to ensure a fresh build from the new source. If the unit builds
under more than one distro, add --distro <distro> to target each. If the build
fails, read the log with yoe log <unit-name> (or
build/<distro>/<unit>/build.log) and use the diagnose workflow to fix it
iteratively.
Step 7: Test Reverse Dependencies
After the unit builds, check if artifacts that depend on it still build:
yoe refs <unit-name>
Build any direct dependents to catch API/ABI breakage:
yoe build --force <dependent-unit>
Step 8: Report Changes
Summarize what changed:
- Version bump (old → new)
- Any dependency changes
- Any configure flag changes
- Any patches added, removed, or updated
- Build and reverse-dependency test results
What NOT to Do
- Do not update to pre-release, alpha, beta, or RC versions unless the user
explicitly requests it.
- Do not remove patches without verifying the fix is in the new version.
- Do not skip the reverse-dependency check — an ABI change in a library can
break all consumers.
- Do not change configure flags without understanding why — research the
upstream changelog and other distributions' units first.
