"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.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 默默壞掉
- 版本策略流派之爭：識別碼是入口、預設行為才是成本的分水嶺
選版本方案時各派的前提與代價：版本識別什麼、變更成本由誰吸收、借用某派結論而不帶其前提會壞在哪
- image 版本管理與升級：不動舊的、建新的
有一個跑著的 stack 要升版（PHP / MySQL 升級）、不想弄壞現在能跑的、又不確定多個版本的 image 跟 Dockerfile 怎麼管時回來讀 — image 不可變下的升級與版本管理