arm-version-progression

Full name

@azure-tools/typespec-azure-resource-manager/arm-version-progression

ARM service api-versions must:

1. Use a unique date — every entry’s YYYY-MM-DD must differ from every other entry’s date in the same Versions enum. A preview version and a stable version cannot share the same date (for example, 2026-04-28 and 2026-04-28-preview together is not allowed).
2. Be declared in strictly increasing chronological order from top to bottom.

This rule complements arm-resource-invalid-version-format, which validates the format of each individual version string. arm-version-progression does not flag malformed version strings — those are reported by the format rule.

❌ Incorrect

A preview and a stable version share the same date:

@versioned(Versions)
@armProviderNamespace
namespace Microsoft.Contoso;

enum Versions {
  v2026_04_28: "2026-04-28",
  v2026_04_28_preview: "2026-04-28-preview",
}

Versions are declared out of chronological order:

@versioned(Versions)
@armProviderNamespace
namespace Microsoft.Contoso;

enum Versions {
  v2024_06_01: "2024-06-01",
  v2024_01_01: "2024-01-01",
}

✅ Correct

@versioned(Versions)
@armProviderNamespace
namespace Microsoft.Contoso;

enum Versions {
  v2024_01_01: "2024-01-01",
  v2024_03_01: "2024-03-01",
  v2024_06_01_preview: "2024-06-01-preview",
}

A stable version followed by a preview that is chronologically later (one day after) is also valid — previews must come chronologically after the most recent stable version:

@versioned(Versions)
@armProviderNamespace
namespace Microsoft.Contoso;

enum Versions {
  v2024_03_01: "2024-03-01",
  v2024_06_01: "2024-06-01",
  v2024_06_02_preview: "2024-06-02-preview",
}