Versions and updates.

Several unrelated version numbers can appear in one workflow. Keep each number with the artifact it identifies when testing compatibility or reporting a problem.

#Name the version you are comparing

Settings shows the client version and release history; it does not certify the deployed backend or update every local tool. A project version guards a save, a Station version freezes a published definition, and package or CLI versions describe separate installed code. Keep the identity relevant to the operation and verify changes in a copy before replacing working content.

The client-only update switches illustrative build A to build B. Project v7, frozen Station v2, package P1 and local software L1 stay unchanged; these symbolic labels are not current release numbers.

#Find the Studio client version

Open Settings → General and look for Version, Released and What's New near the bottom. What's New displays authored release history; it is not an updater.

The version identifies the bundled Studio frontend client. App Installation can show the same version for the installed web app. Neither label proves the exact backend deployment or which optional services are enabled.

Before refreshing or changing software, protect unsaved work and inspect the current save state. Do not use repeated reloads or storage resets to resolve an unknown write outcome.

#Match the version to its purpose

Version	Meaning
Studio client	The frontend build shown in Settings.
Project API version	A conservative optimistic save base used by concurrency checks.
Station version	A frozen published graph, interface and captured package material.
Node package version	A particular published or installed package artifact.
CLI or Runtime version	Software on the machine executing that local tool or service.

A project version is not semantic versioning, browsable history or a backup. Read and reconcile document changes before using a newer expected version. Guarded in-progress or unresolved saves need their own recovery path.

Changing the live Station version is separate from updating Studio. A community package update does not replace the frozen package in an already published Station. The author needs to publish, test and deliberately promote an appropriate Station version.

#Find the instructions that apply

Use Kaitoi News for public announcements and the guide for the feature you use. A version in a development checkout does not establish that the public package or your hosted session has it.

For local tools, follow Install and update and inspect the installed version on the machine doing the work. Updating a local tool does not automatically upgrade Studio, its backend or a separately running service.

Consult the generated API reference for your actual deployment when integrating request fields, scopes and errors. Keep the version and environment with your saved integration example.

#Test an update on a separate copy

Retain the working source and a small example with expected inputs, outputs and errors. Check the updated interface, required provider or service, output files and failure behavior before replacing the original.

For a Station, test the candidate version before making it live. For an application, test the request and response contract in a separate environment. For a local model or recipe, check its dependencies and execution host as well as the CLI package.

When reporting a compatibility issue, include the relevant version labels, environment, run ID and a cleaned reproduction. A client label alone cannot identify every component that participated in the work.