Principles
- The version number source of truth is the
VERSIONfile in the repository. - Every built artifact gets a unique version number.
- Each version is built only once.
- Releases happen without rebuilds but by applying tags to existing builds (Docker image) or updating channel pointers (Companion app).
Process Overview for Test and Preview Candidates
- Update
VERSIONto the next plain numericX.Y.Zbuild sequence ( details ).- Run
./scripts/sync-version. - Commit the synchronized metadata on
main.
- Run
- Build the affected component (see below for details).
- Build workflows reserve the current
VERSIONby adding a Git tag when building from the latest commit. - Alternatively, select an existing
build-vX.Y.ZGit tag to build from.
- Build workflows reserve the current
- Test the resulting build.
- Docker: Through the
testtag. - Companion: Through the Companion draft release assets. Promote them to the Companion
testfeed as needed.
- Docker: Through the
- Repeat the loop with a new
Zvalue when a new candidate is required. Never rebuild or replace a published artifact under the same version.
Notes:
- Docker and Companion candidates may be built independently.
Component Build & Release Process
Update Documentation
- Review the homepage content and update it where necessary.
- Docs:
- Verify Supported File Formats and update as necessary.
- Finalize the target release’s What’s New page.
- Mark the target version as current in
website/data/docs-versions.toml. - Run the VS Code task
Website: Refresh Docs Derived Artifacts. - Review the Docs Structure Report this creates in
/workspace/website-meta/docs-reports/docs-structure-report.html.
- Git merge all changes.
Build Docker Image
See this Overview . In short:
- Run
Release: Create Docker Image
- The workflow:
- Builds the Docker image .
- Moves the
testtag to it. - Adds the
X.Y.Zversion tag.
- The workflow:
- To also move the
betatag to the newly built image, run Release: Publish Docker Image manually.
Build Companion
See this Overview . In short:
- Run
Release: Build Companion Artifact
.
- The workflow creates a draft release in the Companion GitHub repo .
- Publish it.
Publish a Build
To publish a candidate build after testing and validation, complete the following steps.
- Run
Release: Create Public Sambee Release. Specify:- the validated canonical build version.
- the intended scope:
docker,companion, orboth. - whether to publish the resulting draft release in the Sambee GitHub repo,
- The workflow creates a release in the Sambee GitHub repo, either as draft or published.
- If you didn’t select automatic publishing above, publish the draft release manually.
If you selected docker or both:
- Release publication triggers
Release: Publish Docker Image
- The workflow tags the image built earlier as
beta(if not ahead) andstable, and addsX.Ya version tag.
- The workflow tags the image built earlier as
If you selected companion or both:
- Run
Release: Promote Companion Release
.
- The workflow promotes the release to the
test,beta, and/orstableupdate channels and updates the Sambee download-metadata feed.
- The workflow promotes the release to the