Skip to main content
Providers change their APIs on their schedule. Version management is how you absorb that on yours — running old and new side by side, warning consumers before anything moves, and removing a version only once nothing depends on it.

Run more than one version

A workspace service holds a list of enabled versions. Add one and the old one keeps working.
Only the last two are yours — the service slug and the provider’s version string.
In workspace.yaml, versions is a list of objects, one per enabled version — not a list of version strings:
Anything scoped to a version — visibility, execution policy, connection profiles — nests inside that version’s entry. Flat version strings fail to parse, which is deliberate: it stops a policy from drifting away from the version it belongs to.

Announce a deprecation

A deprecation is advisory. It records intent — a date and a reason — while the service stays fully active, so existing SDK and MCP configs keep working while their owners migrate.
Nothing is cut off on the date you set. There is no automatic date-triggered removal. Treat --at as the date you intend to run the delete, once you have confirmed nothing still depends on it.

Remove it for real

Removal is a separate, deliberate step.
If any SDK or MCP config in the same Registry account still references what you are removing, the plan comes back with a blocker instead of quietly breaking those configs. --force accepts that and removes it anyway — and writes a workspace_service_removed or workspace_version_removed notification recording that you made the call.

Flags

workspace service deprecate / workspace service version deprecate

workspace service delete / workspace service version delete

workspace service operations

Check what a version actually offers

Before you point an app at a new version, confirm the operations you depend on still exist under it.
Request and response contracts are opt-in on service operation show — add --include-request or --include-responses — so a large schema does not arrive unless you asked for it.

Ship a new SDK version

Once a new service version is enabled, publish an SDK version that uses it.