OrchestraOS Releases and Maintenance

Release Baselines

An OrchestraOS image is defined by its machine, distribution, image recipe, enabled features, and layer revisions. The public KAS manifests and fragments capture these choices. Reference images provide a starting point for device integration; deployment-specific applications, credentials, and provisioning remain part of the consuming project.

Development manifests such as ci/orcos/orcos-cmdline-rauc-eigm.yml follow the configured layer branches. Their -release.yml counterparts add release fragments that pin dependencies to tags or commits. To reproduce a release, use the top-level repository release tag together with its matching release manifest. A manifest from a later checkout can contain different pins.

ORCOS_VERSION supplies DISTRO_VERSION and the image version suffix. It is an image identifier, not a dependency lock: assigning a version string does not change the selected sources. Preserve the manifest, layer revisions, image package manifest, checksums, and available SBOM with each delivered image.

The software baseline is listed in Software Baseline. Resolve the companion-layer revisions from the release manifest used for the image. Optional extensions document their dependency selection in their own layer repositories.

Maintained LTS Series

OrchestraOS supports Yocto Project long-term support (LTS) versions. See LTS Versions for the available versions and their documentation.

Release Cadence

Major OrchestraOS releases follow the Yocto Project LTS release cycle. Feature releases follow the product roadmap; maintenance releases address applicable CVEs and bug fixes in the participating meta-layers. Security updates can be delivered within a maintained LTS series without changing its Yocto baseline.

Distribution and Access

OrchestraOS source releases and supporting layers are distributed through the CTHINGS.CO Gitea service. Use the release tag and matching KAS release manifests to identify the delivered source baseline.

Commercial extensions and project-specific integrations are provided through the Gitea repositories covered by the customer’s agreement. Access is arranged for the relevant layers and integrations. See Optional Extensions for the available capabilities and licensing contact.

Vulnerability Management

Security fixes can require an OrchestraOS image update independently of a Yocto series transition. Review the selected components, their patches, and the reports generated for the actual image. The common reference configuration enables CVE checking and CycloneDX output; other fragment combinations can disable them. See Software Inventory and Vulnerability Reports.

A vulnerability database match is an input to engineering assessment. Determine whether the affected code is present and reachable, whether a fix is included, and whether deployment mitigations apply. Rebuild and validate the affected platform configuration before delivering an updated image. This document does not assign a fixed remediation deadline or support lifetime to a product.