There are four different version boundaries. Treating them as one number makes upgrades harder than they need to be.
| Boundary | What it identifies | Upgrade behavior |
|---|---|---|
| SDK package | Rules engine and authoring API | A repository pins an exact npm version |
| CLI package | Tooling and local renderer | Loads the game’s installed SDK through host API 1 |
| Deployment release | Exact code, catalog, settings, and artwork | Existing rooms keep their manifest digest |
| Network / presentation protocol | Shared host and browser contract | Breaking changes require an adapter or retained platform generation |
Install an exact SDK version
npm install --save-exact @tabletopwithfriends/sdk@0.1.0
npm install --save-dev --save-exact @tabletopwithfriends/cli@0.1.0The CLI resolves the SDK from the game module’s repository for inspection, simulation, local sessions, and executor builds. It does not substitute its own SDK. An unsupported host API fails explicitly and leaves the game’s files untouched.
Release lines
During 0.x, a minor version is a compatibility line: 0.1.x and 0.2.x can coexist. Breaking changes move to a new minor; patches preserve compatibility. From 1.0 onward, breaking changes require a new major. A maintenance release can be published to an older line without moving npm’s latest tag backward.
Exact versions remain installable. Tags such as sdk-0.1 identify a maintained line, next contains prereleases, and latest points to the newest stable SDK. The version picker opens the documentation snapshot for the installed SDK.
What is not automatic
Historical game executors do not freeze the shared browser renderer. A future incompatible scene or protocol change still needs a compatibility adapter or a preserved host/client generation. This release supports SDK host API 1 and executor protocol 5. The release matrix records these boundaries; it is not a promise that arbitrary future SDKs will run on an older CLI.