SpatialOS release policies
SDK 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 previously warned deprecations.
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.
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.
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. We aim to provide migration paths from older products to new ones.
spatial CLI releases
We release the
spatial CLI separately from the SDKs. When a new
spatial 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
spatial 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
version as soon as you can when a new version is available.
Game engine support
We endeavour to support the latest stable and recommended version of a game engine in either the next minor or major game engine integration release following its launch, or in a release less than 3 months afterwards.
When we introduce support for a new version of a game engine, we always support at least one of the previously supported versions (normally the highest) in parallel, in order to facilitate smooth upgrades.
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 not recommended for production.
Alpha: Feature incomplete and may have some significant bugs. Planned to become stable. APIs in this state will have the term
alphain their namespace, comments, or in the case of the C API, as a prefix to each method name.
Does not adhere to our bug fixing or breaking change policies. Available for testing, but not recommended for production.
Beta: Feature complete, but may still be slightly unstable. APIs in this state will have the term
betain their namespace, comments, or in the case of the C API, as a prefix to each method name.
Does not adhere to our bug fixing or breaking change policies. Available to start building against, but not recommended for production.
Stable: A complete feature that meets the needs of a set of users for production 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.
Not recommended for production.