"Versioning"
- Schema 版本演進策略
Backward compatible 的增量變更 — 新增欄位不改版、改名或改型別才改版、collector 同時支援多版本
- 11.5 版本策略與 deprecation
版本方案怎麼選（URI/header/date-based）、支援窗口怎麼承諾、舊版怎麼安全退場 — 承諾分期與回收的操作設計
- 11.C10 Stripe：日期滾動版本與 version change module
把相容性從路由層搬進轉換層、breaking change 成本由服務端一次吸收；date-based versioning 的原型案例
- 11.C11 Stripe 現行方案：具名 major release 與相容變更清單
同一家公司版本策略隨規模演進的第二個時間切片、附「什麼算 backwards-compatible」的明文清單
- 11.C12 GitHub：REST API calendar versioning 與 24 個月支援承諾
date-based versioning 成為大平台收斂方向的證據點、最低支援窗口把 deprecation 成本變成明文契約
- 11.C13 GitHub：密碼認證廢止的 brownout 執行
deprecation 執行機制案例：公告觸及不到的長尾 client、用排程 brownout 的短暫真實故障叫醒
- 11.C14 Fielding：對 API 版本化的建議是「別做」
no-versioning 流派的理論錨點：hypermedia 演化取代版本號、與運營現實路線分歧的根源
- 11.15 自家行動 App 與後端的 API 契約：版本回報、最低支援版本、商店審核下的上線順序、分階段發布、熱更新與回退手段
自家行動 App 呼叫自家 API 時，在向後相容的變更紀律之外多出的契約機制與決定 API 何時上線的發布約束：請求帶 App 版本、客戶端啟動檢查與伺服器端拒絕兩層組成的最低支援版本、使用者拿不到新版時的處置、商店審核造成的上線順序與送審說明、App Store 與 Google Play 分階段發布的差異、熱更新能改的範圍與兩家商店的條款，以及各回退手段對已安裝版本的作用
- 11.C15 RFC 8594 Sunset header：退場宣告的機器可讀層
用 HTTP header 宣告資源退場時點的標準化嘗試、Informational 地位與實務採用有限
- 11.C16 Slack：四族 API 分階段收斂到 Conversations API
分階段 deprecation 執行：先掐斷新增量、再處理存量、最後硬停、過渡期用 in-band warning
- 11.C17 Facebook Graph API v1.0 退場：靜默語意切換（反例）
反例：到期後把 v1.0 請求靜默當 v2.0 處理而非回明確錯誤、長尾 app 默默壞掉
- 版本策略流派之爭：URI 版本、header 版本、日期 pin 與不做版本的前提與成本
版本識別碼指向什麼、消費者不動作時被解讀成什麼、遷移成本由誰吸收；各派的支援窗口承諾、借用某派結論而不帶其前提的失效形態，以及選型的判定順序
- image 版本管理與升級：不動舊的、建新的
有一個跑著的 stack 要升版（PHP / MySQL 升級）、不想弄壞現在能跑的、又不確定多個版本的 image 跟 Dockerfile 怎麼管時回來讀 — image 不可變下的升級與版本管理
- Minimum Supported Version（最低支援版本）
要讓舊版行動 App 停止使用時：服務方保存的版本下限、客戶端啟動檢查與伺服器端拒絕兩層各自涵蓋哪些版本，以及提高它之前要查的使用者數與作業系統下限