大多數 Azure 服務允許你透過 REST API 程式化控制和管理資源。 服務會透過新發佈的 API 版本演進，並透過不同的合約加入新功能並修改行為。
本文概述 Azure 服務、SDK 和 CLI 小組用來建立 Azure REST API 版本的原則。 雖然 Azure 團隊盡力遵守此政策，但仍可能出現偏差。
服務版本控制
每個已發布的 API 版本都會以格式的日期值 YYYY-MM-DD 來識別，稱為 api-version。 較新的版本有較新版本的日期。
所有 API 操作都需要用戶端透過 api-version URL 中的查詢字串參數指定服務的有效 API 版本。 例如： https://management.azure.com/subscriptions?api-version=2020-01-01 。 用戶端 SDK 和工具會自動包含 api-version 值。 如需詳細資訊，請參閱本文稍後的 用戶端 SDK 和服務版本 一節。
在大多數情況下，服務客戶端只需與單一版本的服務互動，即可存取其所有所需功能。
穩定服務版本一般會維持可用狀態，且支援多年，即使有較新版本可供使用也一樣。 大多數情況下，你會在現有程式碼中採用新的服務版本，以利用新功能。
穩定版本
大多數已發佈的服務版本都是 穩定版。 穩定版本回溯相容，這表示您撰寫的任何依賴一個服務版本的程式代碼都可以採用較新的穩定版本，而不需要任何程式代碼變更來維護正確性或現有功能。
重大變更版本
服務 的重大變更版本 與回溯相容。 在現有客戶端程式碼中採用破壞性變更版本，可能需要修改程式碼以確保客戶端的行為與先前版本相同。
打破性變革版本的版本很少見。 Azure 團隊會透過文件公告，通常會先發布預覽版。 發布重大變更版本可能會促使現有穩定版本最終被淘汰。 這些穩定版本在重大變更版本釋出後至少可持續使用三年。 對於因安全或合規問題而發布的破壞性變更，現有穩定服務版本可能仍可持續使用一年或更短，視問題嚴重程度而定。
由於人工智慧的快速創新與發展，AI 驅動的服務可能將最低可用性縮短為一年。 每個服務都會發布其重大變更政策。
任何依賴非 Microsoft 元件的 Azure 服務，都可以將其支援政策縮減到與該元件的政策相匹配。 任何依賴的破壞性變更都會連結到元件供應商的政策，顯示元件不再支援的日期。
預覽版本
有時候，Microsoft發佈 服務的預覽版本 ，以收集有關建議變更和新功能的意見反應。 預覽服務版本會在api-version中包含後綴-preview，例如2022-07-07-preview。
除非預覽版明確引入與前一個穩定版本的破壞性變更，否則它包含了最新穩定版本的所有功能，並新增了新的預覽功能。 然而，在預覽版本之間，服務可能會破壞任何新增的預覽功能。
預覽不適用於長期使用。 每當服務的新穩定版或預覽版推出時，現有預覽版可能在新版本上線後 90 天內就無法使用。 只有在您主動針對新的服務功能進行開發，且準備在發行后不久採用新的非預覽版本時，才使用預覽版本。 如果預覽版本中的部分功能以新的穩定版本釋出，剩餘的預覽功能通常會以新的預覽版本發佈。
用戶端 SDK 和服務版本
Azure SDK 的目標是在撰寫程式代碼時排除服務版本設定作為考慮。 每個 SDK 都由用戶端連結庫組成，每個服務各有一個，而每個用戶端連結庫版本是以它依賴的單一服務版本為目標。
當您使用 SDK 來存取 Azure 服務時，利用新版本和功能通常需要升級應用程式所使用的用戶端連結庫版本。 新的穩定服務版本伴隨著客戶端連結庫的新點版本。 針對新的重大變更版本，新的用戶端連結庫會發佈為點版本或主要版本。 發行類型取決於服務變更的性質，以及連結庫能夠容納它的方式。 只有 beta-version 用戶端連結庫會使用預覽服務版本。
SDK 用戶端連結庫支援手動覆寫服務版本。 覆寫用戶端函式庫的預設服務版本是進階情境，可能導致意外行為。 如果您使用這項功能，請徹底測試您的應用程式，以確保它如預期般運作。
Azure 命令行工具
如同 SDK，Azure 命令行工具（包括 Azure CLI 和 Azure PowerShell）的設計目的是允許使用 Azure 管理服務，而不考慮版本。 存取新的服務功能通常需要新版本的工具。 每月發行新的回溯相容工具版本。 具有重大變更的版本大約會每年發行兩次，或視需要修正重大安全性問題。
Azure 命令列工具偶爾會揭露預覽功能。 這些指令會標示 Preview 標籤，並輸出警告，表示支援有限及未來版本可能有變動。