SpatialOS release policies
SDK and Runtime releases
SDK and Runtime releases are categorised as major, minor or patch using standard
semantic versioning (
Major releases (for example: 11, 12) include new features and breaking changes for deprecations that we’ve warned about previously.
For major releases, we provide an upgrade guide as well as release notes.
Minor releases (for example: 11.1, 12.1) include new features and no breaking changes.
Minor releases don’t require an upgrade guide, but we provide release notes.
Patch releases (for example: 12.0.1, 12.0.2) contain only bug fixes and no breaking changes.
Patch releases don’t require an upgrade guide. We typically provide release notes.
Each major version of the Worker SDK is only compatible with the same major version of the Runtime. For example, you can’t use version 15 of the Worker SDK with version 14 of the Runtime.
Some features might require you to use a specific minor version of the Worker SDK and the Runtime. For example, you might need version 15.3 of the Worker SDK and version 15.2 of the Runtime. You can find which versions you need in the release notes and documentation for those features.
We support the most recent minor version of the most recent two major versions of SpatialOS (for example: 11.2 and 12.2).
This support includes:
For projects built using a minor version, we support deploying until the later of:
- 9 months after the minor version’s release
- 3 months after the subsequent minor release
We will support the last minor version of supported major versions indefinitely.
We release bug fixes in patch releases on the most recent minor version of supported major versions.
Documentation, tutorials and starter projects
We maintain and update documentation, tutorial and starter projects for the most recent minor version of supported major versions.
Older versions may remain hosted, but are frozen: we do not correct, update or republish them.
Breaking changes and deprecations
Minor versions of SpatialOS are backwards compatible with previous minor versions of the same major version.
This means that: for game code written against Improbable’s public APIs on a given minor version, you’ll be able to update to all subsequent minor versions (of the same major version) without code changes. For example, moving from 12.1 to 12.2, 12.3, 12.4…
Breaking changes (that is, non-backwards-compatible changes) only occur in major versions. We provide any necessary upgrade instructions in the accompanying upgrade guide or in release notes.
To prepare users for these changes, we will (whenever possible) deprecate the API at least one minor or major version before making the breaking change. We’ll announce deprecations in the release notes and/or in compilation warnings.
SpatialOS CLI releases
We release the SpatialOS CLI separately from the SDKs. When a new CLI version is available, you’ll see
a message in the CLI saying that you can run
spatial update to get the latest version.
We deprecate each SpatialOS CLI version 90 days after we release the next version. Once a version is deprecated, it’s possible that commands won’t work, or will behave unexpectedly. We recommend you update your CLI version as soon as you can when a new version is available.
Game engine support
The GDKs for Unreal and Unity only support one stable engine version at a time while they are in alpha. Please refer to each GDK’s setup documentation (Unreal/Unity) for the currently supported version.
Though we strive not to, we do reserve the right to make out-of-policy releases, deprecations, or breaking changes due to issues such as security risks, or fixes with exceptional technical burden.
Pre-alpha: Something that is feature incomplete. Or, part of an existing product that contains a new experiment for a feature. Not necessarily planned to become stable.
Does not adhere to our bug fixing or breaking change policies. Only available to specific customers. Available for testing, but we don’t recommend using it in products that are for public release.
Alpha: Feature incomplete and may have some significant bugs. Planned to become stable. APIs in this state will have the term
alphaprominently displayed in their documentation. In some cases the term
alphaalso appears in their namespace, comments, or as a prefix to each method name.
Does not adhere to our bug fixing or breaking change policies. Available for testing and development, but we don’t recommend using it in products that are for public release.
Beta: Feature complete and potentially with some performance optimisation, but may still be slightly unstable. APIs in this state will have the term
betaprominently displayed in their documentation. In some cases the term
betaalso appears in their namespace, comments, or as a prefix to each method name.
Does not adhere to our bug fixing or breaking change policies. Available for development, but we don’t recommend using it in products that are for public release.
Stable: A complete feature that meets the needs of a set of users for publicly released games. We plan to continue working on this.
Deprecated: Not currently working on or planning to work on features or fixes. Could be removed permanently with notice.
We don’t recommend using it in products that are for public release.