Schema and Artifact Versions
Holoscan uses independently versioned contracts for application schemas, serialized artifacts, Channel protocols, native descriptors, and internal compiler interfaces. A version identifies one of those contracts; it does not count SDK releases.
This reference records the current values in the Holoscan SDK 5.0 source and links to their definitions. It covers the nine contracts above v1 examined during the GA versioning review, plus related contracts still at v1. Private implementation contracts are included to help interpret artifacts and diagnostics; their inclusion does not make them public extension interfaces.
Stable C++ and Python source APIs, native binary compatibility, serialized formats, and cross-process interoperability have separate boundaries. Use API stability for the source compatibility policy and the individual guides for supported deployment combinations.
Application schemas have their own identities
Application-owned schemas are separate from the SDK-owned versions listed below:
For example, an application’s parameter schema version can be 1 while its
snapshot is stored in archive format v1 and its generated plan uses private
plan schema v9. Those three numbers describe different contracts. Likewise,
the schema-family derivation domain /v2 below is independent of a
FlatBuffer family’s authored compatibility epoch.
Current SDK contracts above v1
Values below describe this SDK source revision. The linked definitions and consumers are authoritative when auditing another revision.
A shared numeric value does not establish compatibility between these rows. The Channel sample descriptor ABI, catalog JSON, and health-control frame are all at version 2, but each reader checks a different contract.
Related contracts already at v1
These contracts evolve independently of the higher versions above. This is a selected inventory, rather than a list of every versioned SDK field or third-party protocol.
Read and upgrade artifacts deliberately
- Identify the family first: a parameter schema, plan JSON, catalog, native descriptor, wire frame, or hash domain. Use that family’s version field or identifier when selecting a reader; the enclosing SDK version alone is insufficient.
- Check the reader or package’s supported contract. For example, runtime-package matching checks required plan schemas explicitly, and Channel frame decoders reject unsupported versions. A version field does not add negotiation or migration.
- Follow the release’s rebuild and matching-deployment requirements. Regenerate deployment artifacts with the intended SDK and review schema versions when comparing plan JSON or digests across SDK upgrades. Use the documented plan accessors and artifact APIs to inspect and publish them.
Source API stability alone does not establish cross-version readers, writers, or runtime-peer interoperability. A compatible application-owned schema edit also needs to fit its declared bounds and the supported deployment contract.