Release policy
Semantic versioning
Turian follows semantic versioning (major.minor.patch — for example v1.9.0).
- Major increments mean breaking changes — your project may need manual updates.
- Minor increments add features, but existing code continues to compile without changes.
- Patch increments ship bug fixes and performance improvements with no API changes.
We do not believe in keeping the major version at 0 indefinitely. Turian has been
at v1.x.x since v1.0.0, when it became possible to create a game from scratch
and build it into a standalone executable. "Production-ready" will be a project
decision and announcement, never a version number.
Major releases are technical, not marketing
In most engines a new major version is an event: years of features bundled behind a single number, announced at a keynote, followed by a long and risky migration. Turian takes the version number literally instead. A major release means exactly one thing — something changed in a way that can break existing projects — and it ships the same day as any other release, sometimes carrying a single breaking change and nothing else.
What you can rely on:
- Every major release has a matching entry in the migration guides telling you exactly what changed and what (if anything) you must do.
- Breaking data-format changes come with a migration path, not just a
changelog line: old files keep loading (with a warning) and a batch tool
(
turian-cli migrate) persists the conversion across a whole project. - Because breaking changes are released as they land instead of being saved up for a "big" version, each migration is small and reviewable on its own.
The "what's new in Turian" story lives elsewhere: periodic roundup posts on the blog summarize features and fixes across many releases, independent of version numbers.
Release frequency
We ship a new release every day (when there is a code change). This means bug fixes and features reach you the day they are merged, instead of sitting in a queue for months waiting for the next "big" release.
The advantages of high-frequency releases:
- A bug you report today is fixed in a release tomorrow — no waiting for a quarterly milestone.
- Regression hunting is easier because the diff between consecutive releases is small.
- You can always pin to a specific version and upgrade at your own pace.
We may reduce the frequency in the future once the project stabilises, but the philosophy will remain: ship early, ship often.
Long-term support
We do not offer long-term support (LTS) releases. The project is in its infancy and the API is evolving rapidly. Maintaining an LTS branch would slow development and fragment the community. The best way to stay on a supported version is to follow the latest release.
Multiple versions installed
SDK binary releases are fully relocatable and self-contained. Each release extracts to its own folder, so multiple versions can coexist on the same machine without conflicts. The SDK ships the engine source, editor source, dependencies, and the CLI binary — everything needed to build a game.
~/sdks/turian-sdk-linux-x86_64-v1.8.0/turian-cli build mygame # v1.8.0
~/sdks/turian-sdk-linux-x86_64-v1.9.0/turian-cli build mygame # v1.9.0
Each turian-cli binary resolves its own sibling engine sources through the
turian-sdk.json marker next to it. Your project's output is always compiled
against the exact version you invoked. See the Install page
for more details on SDK layout and version coexistence.