The SDK consists of various components, tools, and language interfaces released under a common versioning scheme. Below, we explain how the overall SDK and its individual components are versioned, along with the associated compatibility promises.

Versioning Scheme

We use a dual versioning approach: Calendar Versioning (CalVer) for the overarching SDK releases, and Semantic Versioning (SemVer) for the individual components contained within the SDK.

SDK Versioning (CalVer)

The SDK is distributed as a bundled release using Calendar Versioning (see calver.org). The SDK version number reflects the release date (e.g., 26.06 or 2026.11), serving as an identifier for a tested and validated snapshot of all included components at that point in time. Updating the SDK means updating your environment to this validated collection of components.

Component Versioning (SemVer)

While the SDK bundle uses CalVer, the individual software components, tools, and libraries inside it follow Semantic Versioning (SemVer) (see semver.org). Each component's release is identified by a major, minor, and patch number, separated by dots (e.g., 1.2.1).

• Major releases increment the major version number and reset the minor and patch numbers to zero. Major releases introduce incompatible API changes.
• Minor releases increment the minor version number and reset the patch version number to zero. Minor releases add functionality in a backward-compatible manner.
• Patch releases increment only the patch version number. They contain backward-compatible bug fixes.

Language Interfaces (Python & .NET) and the 4th Digit

While the core components follow strict Semantic Versioning, interface-specific maintenance fixes may introduce an optional fourth digit without implying any change to the underlying API:

• Baseline Alignment: By default, language interfaces strictly mirror the 3-digit version of the core component.
• Interface Patches: If an issue or packaging error occurs solely within the Python or .NET wrapper while the underlying API remains unchanged, the fourth digit is incremented (e.g., from 1.0.0 to 1.0.0.1).
• Omission of Zero: The fourth digit is omitted from the version string until it is required. It is not displayed as .0 during regular Major, Minor, or Patch releases (e.g., a release is written as 1.0.0, never 1.0.0.0).

Compatibility Promises

As your project evolves, and you update to newer SDK releases, your existing code should continue to work seamlessly. Because compatibility is dictated by the APIs, our compatibility guarantees apply to the Semantic Versioning of the individual components, rather than the CalVer of the SDK bundle.

We provide clear compatibility guarantees for all component releases sharing the same SemVer major version number.

Source Compatibility

Source compatibility means that an application developed against one component release can be compiled against other releases of that component within the same major version without source code changes.

We aim to maintain source compatibility with previous releases of the same major version. An application developed against a component's API 1.0.0 is expected to compile when built with any other 1.x.y release of that component (though deprecation warnings for outdated features may be shown).

‍Note: Parts marked as experimental are excluded from this promise.

Binary Compatibility

Binary compatibility means that an application compiled against one component release can run with another compatible release of that component without recompilation.

We guarantee backward binary compatibility (ABI stability) within the same major version of a component. An application compiled against component version 1.0.0 will run with any newer 1.x.y release — however, an application compiled against a newer release is not guaranteed to run with older component versions.

‍Note: This promise applies under the condition that the same toolchain (compiler) and system environment are used for both versions.