Skip to content

Versioning and deprecation

GraphPilot has three parts that change on their own schedule: the edge runtime your services run on, the gpilot CLI, and the GraphPilot API behind the portal and the CLI.

Every service runs a version of the GraphPilot proxy runtime. A deployed service keeps the runtime it was built with until its next deployment, so a new runtime version never reaches a service on its own.

  • Unpinned, a service follows the stable version and moves to a new one on its next deployment.
  • Pinned, it stays on the version you chose, in the portal (Service settings, Runtime) or with gpilot service runtime pin <version>. One deployment can also name a version in [runtime].

A version is in one of three states: active (offered), deprecated (still served, no longer offered), or withdrawn (no longer offered or deployable). A service on a withdrawn version is flagged in the portal; what moves it off depends on its pin. See runtime versions, which also lists every version and its state.

Before any command that talks to the GraphPilot API, gpilot reads a published version manifest and checks the minimum version GraphPilot supports. A new release is normally published as the new minimum. Behind the latest release, the CLI prints a notice; below the minimum, it refuses API commands and exits with 6. Commands that never leave your machine are not checked. See staying up to date, including what to do with a pinned CLI in CI.

The GraphPilot API has one endpoint and no version number. Most changes add types, fields and arguments, which an existing client does not notice. When a field is replaced, the old one is marked deprecated in the schema, with a deprecationReason naming its replacement, and keeps answering; for example, Deployment.creatorApiKey is deprecated in favor of Deployment.requestedBy. A change that removes something or changes what it means, such as a new required argument or a stricter permission, is a breaking change.