Kubernetes 釋出週期

針對釋出里程碑的增強、問題和 PR

本文件面向需要建立針對特定釋出里程碑的增強、問題或拉取請求 (PR) 的 Kubernetes 開發人員和貢獻者。

• TL;DR
  • 正常開發（第 1-11 周）
  • 程式碼凍結（第 12-14 周）
  • 釋出後（第 14 周及以後）
• 定義
• 釋出週期
• 從里程碑中刪除項
• 向里程碑新增項
  • 里程碑維護者
  • 功能新增
  • 問題新增
  • PR 新增
• 其他必需標籤
  • SIG 所有者標籤
  • 優先順序標籤
  • 問題/PR 型別標籤

將增強、問題和拉取請求引入 Kubernetes 釋出的流程涉及多個利益相關者

• 增強、問題和拉取請求所有者
• SIG 領導層
• 釋出團隊

工作流和互動資訊如下所述。

作為增強、問題或拉取請求（PR）的所有者，您有責任確保滿足釋出里程碑要求。如果需要更新，自動化和釋出團隊將與您聯絡，但 inaction 可能會導致您的工作從里程碑中移除。當目標里程碑是之前的釋出時，存在額外的要求（有關更多資訊，請參閱cherry pick 流程）。

TL;DR

如果您的 PR 要被合併，它需要以下必需的標籤和里程碑，此處由 Prow /commands 表示，它們將用於新增這些標籤

正常開發（第 1-11 周）

• /sig {名稱}
• /kind {型別}
• /lgtm
• /approved

程式碼凍結（第 12-14 周）

• /milestone {v1.y}
• /sig {名稱}
• /kind {bug, failing-test}
• /lgtm
• /approved

釋出後（第 14 周及以後）

返回“正常開發”階段要求

• /sig {名稱}
• /kind {型別}
• /lgtm
• /approved

合併到 1.y 分支現在透過 cherry pick，由釋出經理批准。

過去，里程碑目標的拉取請求需要有一個相關的 GitHub issue，但現在不再是這樣。功能或增強實際上是 GitHub issues 或KEP，它們會產生後續的 PR。

通用的標籤流程應在所有工件型別中保持一致。

定義

• 問題所有者：建立者、受讓人以及將問題移入釋出里程碑的使用者

• 釋出團隊：每個 Kubernetes 版本都有一個執行專案管理任務的團隊，其描述見此處。

  任何給定版本團隊的聯絡資訊可在此處找到。

• Y 天：指工作日

• 增強功能：參見“我的東西是增強功能嗎？”

• 增強凍結：為了使增強功能成為當前版本的一部分，KEP 必須完成的截止日期

• 例外請求：請求延長特定增強功能截止日期的過程

• 程式碼凍結：在最終釋出日期之前大約 4 周的時期，在此期間只有關鍵的錯誤修復才能合併到釋出中。

• 裁剪：如果增強功能未完全實現或被認為不穩定，則將其從釋出里程碑中移除的過程。

• 釋出里程碑：語義版本字串或GitHub 里程碑，指代釋出 MAJOR.MINOR vX.Y 版本。

  另請參閱釋出版本控制。

• 釋出分支：為 vX.Y 里程碑建立的 Git 分支 release-X.Y。

  在 vX.Y-rc.0 版本釋出時建立，並在釋出後維護大約 12 個月，釋出 vX.Y.Z 補丁版本。

  注意：1.19 及更高版本將獲得 1 年的補丁版本支援，而 1.18 及更早版本將獲得 9 個月的補丁版本支援。

釋出週期

Kubernetes 目前每年大約釋出三次。

釋出過程可分為三個主要階段

• 增強功能定義
• 實現
• 穩定化

但實際上，這是一個開源和敏捷專案，功能規劃和實現一直在進行。鑑於專案規模和全球分散式開發人員基礎，專案速度的關鍵在於不依賴於滯後的穩定化階段，而是進行持續整合測試，確保專案始終穩定，以便可以標記單個提交是否導致了問題。

隨著全年持續進行的功能定義，一些專案將浮現出來，並被指定為某個版本的目標。**增強功能凍結** 在釋出週期大約第 4 周開始。屆時，給定版本的所有預期功能工作都已與釋出團隊的增強負責人一起定義在合適的規劃工件中。

增強功能凍結後，跟蹤 PR 和問題上的里程碑非常重要。里程碑中的專案被用作完成釋出的待辦事項清單。在問題上，里程碑必須透過 SIG 的分類正確應用，以便釋出團隊可以跟蹤錯誤和增強功能（任何與增強功能相關的問題都需要一個里程碑）。

有一些自動化功能可以幫助自動將里程碑分配給 PR。

此自動化目前適用於以下儲存庫

• kubernetes/enhancements
• kubernetes/kubernetes
• kubernetes/release
• kubernetes/sig-release
• kubernetes/test-infra

在建立時，針對 `master` 分支的 PR 需要人工提示他們可能希望 PR 針對哪個里程碑。一旦合併，針對 `master` 分支的 PR 會自動應用里程碑，因此從那時起對該 PR 里程碑的人工管理就不那麼必要了。對於針對釋出分支的 PR，里程碑在 PR 建立時會自動應用，因此根本不需要人工管理里程碑。

任何其他應由釋出團隊跟蹤但不在自動化範圍內的任務都應指定一個里程碑。

實施和錯誤修復貫穿整個週期，但最終在程式碼凍結期達到高潮。

程式碼凍結 在第 12 周左右開始，持續約 2 周。在此期間，只有關鍵的錯誤修復才能被接受到釋出程式碼庫中。

在程式碼凍結之後，釋出之前，大約有兩週的時間，在此期間必須解決所有剩餘的關鍵問題，然後才能釋出。這也為文件的最終確定提供了時間。

當代碼庫足夠穩定時，master 分支將重新開放以進行通用開發，並開始為下一個釋出里程碑工作。當前版本的任何剩餘修改都將從 master cherry pick 回到釋出分支。該版本將從釋出分支構建。

每個版本都是更廣泛的 Kubernetes 生命週期的一部分

從里程碑中刪除項

在深入探討將專案新增到里程碑的過程之前，請注意

釋出團隊成員可能會從里程碑中刪除問題，如果他們或負責的 SIG 確定該問題實際上並未阻止釋出，並且不太可能及時解決。

釋出團隊成員可能由於以下任何或類似原因從里程碑中移除 PR

• PR 可能會破壞穩定性，並且不需要解決阻塞問題
• PR 是一個新的、遲來的功能 PR，尚未經過增強流程或例外流程
• 沒有負責的 SIG 願意承擔 PR 的所有權並解決任何後續問題
• PR 標籤不正確
• PR 的工作明顯停止，交付日期不確定或延遲

雖然釋出團隊成員將協助標籤和聯絡 SIG，但提交者有責任對 PR 進行分類，並獲得相關 SIG 的支援，以保證 PR 導致的任何問題將迅速解決。

如果需要額外操作，釋出團隊將透過以下渠道嘗試進行人與人之間的升級

• 在 GitHub 中評論，根據問題型別適當提及 SIG 團隊和 SIG 成員
• 傳送電子郵件至 SIG 郵件列表
  • 從社群 SIG 列表中獲取群組電子郵件地址
  • 也可以選擇直接向 SIG 領導層或其他 SIG 成員發函
• 在 SIG 的 Slack 頻道中發訊息
  • 透過社群 SIG 列表中的 Slack 頻道和 SIG 領導層進行引導
  • 可以選擇直接“@”提及 SIG 領導層或其他成員

向里程碑新增項

里程碑維護者

milestone-maintainers GitHub 團隊的成員被賦予在 GitHub 工件上指定釋出里程碑的責任。

該團隊由 SIG Release 維護，並由各個 SIG 的領導層代表。

程式碼凍結後，嚴禁將正在進行的釋出里程碑新增到拉取請求中，因為這可能會損害發布的穩定性。在進行此類更改之前，必須獲得釋出團隊負責人和退休顧問的批准。

功能新增

功能規劃和定義如今有多種形式，但一個典型的例子可能是在KEP中描述的大量工作，並在 GitHub 中包含相關的任務問題。當計劃達到可實現狀態並正在進行工作時，透過建立 GitHub 問題並使用 Prow "/milestone" 命令標記它們，增強功能或其部分將被指定為即將到來的里程碑。

在釋出週期的前約 4 周內，釋出團隊的增強功能負責人將透過 GitHub、Slack 和 SIG 會議與 SIG 和功能所有者進行互動，以收集所有所需的規劃工件。

如果您有一個要針對即將到來的釋出里程碑的增強功能，請與您的 SIG 領導層和該釋出的增強功能負責人開始對話。

問題新增

問題透過 Prow "/milestone" 命令標記為目標里程碑。

釋出團隊的Bug 分類負責人和整個社群會關注傳入的問題並對其進行分類，如貢獻者指南中關於問題分類的部分所述。

用里程碑標記問題使社群更好地瞭解問題何時被發現以及社群認為何時必須解決。在程式碼凍結期間，必須設定一個里程碑才能合併 PR。

PR 不再需要開啟的 issue，但開啟的 issue 和相關的 PR 應該有同步的標籤。例如，如果一個高優先順序 bug issue 的相關 PR 僅被標記為低優先順序，則該 PR 可能不會被合併。

PR 新增

PR 透過 Prow "/milestone" 命令標記為目標里程碑。

如上所述，這是程式碼凍結期間的阻塞要求。

其他必需標籤

以下是標籤及其用途和目的列表。

SIG 所有者標籤

SIG 所有者標籤定義了當里程碑問題停滯不前或需要額外關注時，我們將上報給哪個 SIG。如果上報後沒有更新，問題可能會自動從里程碑中移除。

這些標籤透過 Prow "/sig" 命令新增。例如，要新增表示 SIG Storage 負責的標籤，請評論 /sig storage。

優先順序標籤

優先順序標籤用於確定在將問題從釋出里程碑中移出之前的升級路徑。它們還用於確定釋出是否應因該問題的解決而被阻止。

• priority/critical-urgent：絕不能自動移出釋出里程碑；透過所有可用渠道持續向貢獻者和 SIG 升級。
  • 被視為阻礙釋出的嚴重問題
  • 在程式碼凍結期間，需要問題所有者每天更新
  • 如果在次要版本釋出後才發現，則需要釋出補丁
• priority/important-soon：升級給問題所有者和 SIG 所有者；多次升級嘗試失敗後，將問題移出里程碑。
  • 不被視為阻礙釋出的嚴重問題
  • 不需要釋出補丁
  • 在程式碼凍結後，經過 4 天的寬限期，將自動移出釋出里程碑
• priority/important-longterm：升級給問題所有者；嘗試 1 次後，將問題移出里程碑。
  • 甚至比 priority/important-soon 更不緊急/關鍵
  • 比 priority/important-soon 更積極地移出里程碑

問題/PR 型別標籤

問題型別用於幫助識別隨著時間推移進入釋出版本中的變更型別。這可能使釋出團隊更好地瞭解如果釋出節奏加快，我們會遺漏哪些型別的問題。

對於目標為釋出的 issue，包括拉取請求，必須設定以下 issue 型別標籤之一

• kind/api-change：新增、刪除或更改 API
• kind/bug：修復新發現的錯誤。
• kind/cleanup：新增測試、重構、修復舊錯誤。
• kind/design：與設計相關
• kind/documentation：新增文件
• kind/failing-test：CI 測試用例持續失敗。
• kind/feature：新功能。
• kind/flake：CI 測試用例間歇性失敗。