Versioning
SDK semver, PROTOCOL_VERSION semantics, and how breaking changes are handled.
Versioning
The Cosmo Realtime SDK has two independent version axes: the SDK package version and the wire protocol version.
SDK package versions
The three SDKs follow Semantic Versioning independently:
| Package | Current version |
|---|---|
cosmo-ai (TypeScript) | 0.1.0 |
cosmo-ai-sdk (Python) | 0.1.0 |
CosmoRealtime (Swift) | 0.1.0 |
MAJOR — incremented on breaking changes to the public API surface (renamed exports, removed methods, changed required parameters). Requires a migration step.
MINOR — new capabilities added in a backward-compatible way (new methods, new optional fields, new events).
PATCH — backward-compatible bug fixes, documentation updates, internal refactors that don't change behavior.
All three SDKs target the same protocol version and are released together when the wire protocol changes.
PROTOCOL_VERSION
The wire protocol carries a separate version string: PROTOCOL_VERSION = "1.0".
This version is exchanged on session start:
- The client sends
versioninRealtimeClientInit. - The server echoes it in
RealtimeReadyand validates compatibility.
If the server finds the client version incompatible, it replies with RealtimeError(code="version_mismatch") before closing the session. The SDK surfaces this as auth_error in TypeScript and RealtimeErrorCode.VERSION_MISMATCH in Python/Swift.
The protocol version is independent of the SDK package version. A patch release of cosmo-ai that fixes a bug does not change PROTOCOL_VERSION.
When PROTOCOL_VERSION bumps
The protocol version increments on:
- Renamed or removed fields on any wire message.
- Changed discriminator values (
typestring changed). - Required fields added to a message that previously made them optional.
- Changed semantics of an existing field that could break a correctly-behaving client.
It does not increment on:
- New optional fields added to a message.
- New message types that older clients silently ignore.
- New server error codes (clients switch on known codes and fall back to
server_errorfor unknowns).
Backward compatibility guarantees
For minor and patch releases:
- Existing optional fields remain optional.
- New fields added to request bodies are optional with backward-compatible defaults.
- New server message types are silently ignored by SDKs that don't handle them.
- New
RealtimeErrorCodevalues fall through to theserver_errorbucket in the TypeScript SDK. - New event names on
RealtimeEventMapare ignored by handlers that don't subscribe to them.
Upgrade path
When a new major version ships:
- A migration guide is published in the changelog.
- The old major remains supported for a deprecation window (announced in the changelog).
- The
PROTOCOL_VERSIONbump is accompanied by a new SDK major if it requires client-side changes.
Checking the version at runtime
// TypeScript — the package version is not readable at runtime; `cosmo-ai`
// exports no version constant and its `exports` map does not expose
// package.json. Pin the version in your own build instead.
import { PROTOCOL_VERSION } from 'cosmo-ai';
console.log(`Client speaks protocol ${PROTOCOL_VERSION}`); // "1.0"# Python
import importlib.metadata
print(importlib.metadata.version("cosmo-ai-sdk"))// Swift — package version is embedded in the generated client's User-Agent
print("Client speaks protocol \(RealtimeSession.protocolVersion)")The protocol version is a runtime constant in TypeScript (PROTOCOL_VERSION) and Swift (RealtimeSession.protocolVersion); both are the version the client speaks. For the server's, read the version field from a ReadyEvent after connecting.