.. _os-release-cycle: #################################### 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 :ref:`os-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 :ref:`os-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 :ref:`os-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 :ref:`os-sbom`. 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.