> This page is for AI Cluster Runtime, version Latest · v1.0.0 (default).
> For other versions, use one of these documentation indexes:
> - Latest · v1.0.0 (default): https://docs.nvidia.com/aicr/latest/llms.txt
> - v1.0.0: https://docs.nvidia.com/aicr/v1.0.0/llms.txt
> - v0.22.0: https://docs.nvidia.com/aicr/v0.22.0/llms.txt
> - v0.21.1: https://docs.nvidia.com/aicr/v0.21.1/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/aicr/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/aicr/_mcp/server.

# Deprecations

Every active AICR deprecation, the replacement, and the release that removes it.
An entry stays on this page until the removal ships, then moves to
[Removed](#removed) for one further release so an operator upgrading across
several versions can still find out what happened.

The policy behind this page — what counts as a breaking change on each surface,
and the notice a removal owes — is in
[`RELEASE.md`](https://github.com/NVIDIA/aicr/blob/main/RELEASE.md#deprecation-policy).

## How you will find out

You do not have to read this page to be warned. Every deprecation is announced
on the affected surface through that surface's own channel — which is not always
a runtime warning, because the most useful moment to be told differs by surface:

| Surface | What you see | When |
|---|---|---|
| CLI | A warning on stderr naming the replacement and the removal release | At run time |
| REST | A `Deprecation` header ([RFC 9745](https://www.rfc-editor.org/rfc/rfc9745.html)) with the deprecation date, a `Sunset` header ([RFC 8594](https://www.rfc-editor.org/rfc/rfc8594.html)) with the removal date, a `Link` with `rel="deprecation"`, and `deprecated: true` on the operation in the OpenAPI spec | On every response |
| Go SDK | A `// Deprecated:` godoc marker, which `staticcheck` reports as `SA1019` | At **build** time |
| Bundles and artifacts | A loader warning naming the file and the release that stops reading it | When the artifact is read |

The Go SDK is deliberately build-time rather than run-time: the compiler and
your linter can tell you before you ship, which beats a log line from
production.

That announcement is the contract. If something was removed without one, that is
a bug worth [filing](https://github.com/NVIDIA/aicr/issues/new/choose).

## Active

### Alpha artifact `apiVersion` values

**Surface:** bundle and artifact schemas ·
**Deprecated in:** v0.22 · **Removed in:** v1.0.0 — **this removal has happened**

Every artifact AICR generates carried an alpha `apiVersion` — `aicr.run/v1alpha2`
for most kinds, `aicr.run/v1alpha3` for profile-bearing recipes. Those values were
replaced by maturity-appropriate targets, per
[ADR-022](https://github.com/NVIDIA/aicr/blob/main/docs/design/022-artifact-maturity-and-deprecation.md).

| Kind | Retired | Replacement |
|---|---|---|
| `Snapshot`, default `RecipeResult`, `RecipeCriteria`, `BundleProvenance` | `aicr.run/v1alpha2` | `aicr.run/v1` |
| `AICRConfig`, catalog `RecipeMetadata`, `RecipeMixin`, `ComponentRegistry` | `aicr.run/v1alpha2` | `aicr.run/v1beta1` |
| Profile-bearing `RecipeMetadata` and `RecipeResult` | `aicr.run/v1alpha3` | `aicr.run/v1beta2` |

**What to do.** Generated artifacts — snapshots, resolved recipes, bundle
provenance — are recaptured or regenerated by re-running the command that
produced them. Files you authored — `AICRConfig`, and any external
`RecipeMetadata`, `RecipeMixin`, or `ComponentRegistry` in a `--data` catalog —
are edited by hand. AICR has no conversion layer and does not rewrite your
catalog.

**The window was v0.22 only, and it has closed.** v0.21 and v0.22 read both the
alpha and the target values; v1.0.0 reads only the target, and rejects an alpha or
absent `apiVersion` with a message naming the value, the expected value, and the
release that withdrew it. An archived artifact whose source cannot be recaptured
stays readable only with a retained v0.21 or v0.22 binary. See
[catalog and binary compatibility](/aicr/integrator-guide/data-extension#catalog-and-binary-compatibility)
for the release-by-release table.

**Go importers.** The retirement also removed the exported `pkg/header`
identifiers that named the alpha values. `pkg/header` sits outside the
`pkg/client/v1` SDK surface the API compatibility gate covers, so this reaches
you as a compile error rather than a recorded API break.

| Removed | Replace with |
|---|---|
| `APIVersionV1Alpha2` | the bare segment for your track — `APIVersionV1`, `APIVersionV1Beta1`, or `APIVersionV1Beta2` |
| `APIVersionV1Alpha3` | `APIVersionV1Beta2`; it only ever named the profile-bearing track |
| `GroupVersion` | the full group/version for your track — `GroupVersionV1`, `GroupVersionV1Beta1`, or `GroupVersionV1Beta2` |
| `RecipeResultGroupVersion` | `GroupVersionV1Beta2`, for the same reason |
| `WarnDeprecatedAPIVersion` | nothing — a retired value is rejected now, not warned about. `RetirementNote` supplies the `(… was retired in v1.0.0)` clause for the rejection message |
| `ResetAPIVersionRecorderForTest` | nothing — the warning recorder it reset is gone |

The two constant families are not interchangeable: an `APIVersion*` constant is
a bare segment (`v1beta1`), while a `GroupVersion*` constant carries the group
as well (`aicr.run/v1beta1`). Use the Kind table above to pick your track, and
alias the constant rather than the string it happens to equal — the tracks hold
distinct values now, so a collapsed alias shows up as a wrong value rather than
a latent one.

### Empty `apiVersion` on artifacts

**Surface:** bundle and artifact schemas ·
**Deprecated in:** v0.22 ·
**Removed in:** v1.0.0 for `Snapshot`, `RecipeCriteria`, and `RecipeResult`
inputs — **this removal has happened**; **already removed in v0.21** for
`RecipeMetadata` overlays

Artifacts predating the `apiVersion` field loaded with the field absent or
empty. That tolerance retired alongside the alpha values — except for
`RecipeMetadata`, which lost it a release early and without a warning window;
see below.

One narrowing landed earlier than the rest: as of v0.21, a `RecipeMetadata`
overlay passed directly (`aicr bundle -r overlay.yaml`,
`aicr validate -r overlay.yaml`) must carry an `apiVersion`, because the catalog
scanner already required one and the two paths disagreed on the same bytes
([#2421](https://github.com/NVIDIA/aicr/issues/2421)). `Snapshot`,
`RecipeCriteria`, and hydrated `RecipeResult` inputs kept the tolerance until
v1.0.0.

**What to do.** Add an `apiVersion` header to any artifact you author or retain.
Use the target value from the table above, not the alpha one — v0.21 onward
accepts both, and only the target survives v1.0.0.

### Bundle-time GPU allocation-policy overrides

**Surface:** bundle value overrides ·
**Deprecated in:** v0.17 · **Removed in:** not scheduled

A static bundle-time override (`--set`, `--set-json`, `--set-file`, or a config
file) of a key that selects the GPU allocation policy still applies, but warns.
The keys are `devicePlugin.enabled` on `gpu-operator`(`-ocp`),
`resources.gpus.enabled` and `gpuResourcesEnabledOverride` on
`nvidia-dra-driver-gpu`(`-ocp`), and the `enabled` toggle of those components.
Validators verify the allocation policy resolved from the recipe, so a
bundle-time change is reported as recipe/cluster drift. `--dynamic` on these
keys is already rejected. See
[Configured GPU allocation policy](/aicr/user-guide/validation#configured-gpu-allocation-policy).

No removal release is set yet, so the warning does not name one.

**What to do.** Set the allocation mode in a recipe overlay instead of at
bundle time.

### Bundle-time `slinky-slurm:accounting.enabled` on legacy Slurm recipes

**Surface:** bundle value overrides ·
**Deprecated in:** v0.19 · **Removed in:** not scheduled

A Slurm recipe that records no accounting mode (no
`configuration.slurm.accounting`) predates `--slurm-accounting-mode`. Bundling
one with a `slinky-slurm:accounting.enabled` override still works, but warns:
the override selects only customer-managed accounting, and it is not recorded
in recipe evidence. On a recipe that records a mode, the same override is
rejected; see [Slurm Accounting](/aicr/user-guide/slurm-accounting).

No removal release is set yet, so the warning does not name one.

**What to do.** Regenerate the recipe with `--slurm-accounting-mode` (for
example `customer-managed`) and drop the override.

## Removed

Nothing has completed a removal cycle yet. The first entries land in v1.0.0.