Upgrade and compatibility
InferCrane v1 separates four compatibility surfaces: the control API, DeploymentSpec, integration contracts, and PostgreSQL schema. A passing runtime or provider conformance test does not override the policy for another surface.Before upgrading
- Read the release notes and compatibility matrix.
- Back up PostgreSQL and verify the dump with
pg_restore --list. - Run
infercrane planfor representative DeploymentSpecs with the new CLI. - Run local qualification against the exact candidate commit.
- Verify provider credentials and inventory with
infercrane doctorandinfercrane orphans. - Upgrade the control plane before upgrading generated SDKs or automation clients.
PostgreSQL migration contract
Migrations are embedded, ordered, forward-only, and transactionally applied under a PostgreSQL advisory lock. The migration ledger stores a SHA-256 checksum for every migration. Startup fails if:- a previously applied migration was edited;
- the ledger has a gap;
- the database contains a migration unknown to the running binary; or
- a migration cannot commit atomically.
DeploymentSpec
The current file contract is:Control API and SDKs
/api/v1 is the stable v1 namespace. Within v1:
- new optional response fields are additive;
- clients must ignore response fields they do not understand;
- existing field meaning and error codes do not change silently;
- removal requires deprecation in release notes for at least two minor releases;
- generated SDK major versions track the API major version.
--output json, the generated SDKs,
or Terraform.
Provider and runtime contracts
Provider Contractinfercrane.provider/v1 and Runtime Contract infercrane.runtime/v1 are versioned
separately from the product. Registration exposes an adapter to composition; only the capability and
qualification inventory establishes evidence for an exact runtime/provider/mode combination.
Rolling upgrades
Every live replica registers its binary version and control protocol interval. Startup fails before serving when that interval cannot overlap a live member. Inspect the actual window:/readyz and the membership list, then remove old replicas one
at a time. An expired operation lease is reclaimed by another worker; the old fence token cannot
checkpoint or complete work. This is not permission to mix arbitrary schema versions: take a verified
backup first and follow the migration compatibility statement for both releases.
Rotate server or client certificates by temporarily trusting both CA generations, rolling clients,
then servers, and finally removing the old CA. InferCrane reads certificate files at process startup,
so each trust change requires a graceful rolling restart.