發布流程

這份文件說明瞭 Fuchsia 平台的發布程序。

在本文件中，「版本」一詞是指產生及發布各種成果供開發人員深入軟體供應鏈使用的行為 (例如元件作者或產品擁有者)。「不」是指針對 Fuchsia 型產品向使用者提供更新的行為。

版本

Fuchsia「版本」是一組產生的構件，這些構件是 Fuchsia 專案在特定時間點的輸出內容，且會透過特定的發布版本名稱發布。

內容如下：

  • 整合商開發套件 (IDK)，這是用來建構及執行以 Fuchsia 為目標的少數程式庫、套件和工具。
    • 以 IDK 為基礎的 SDK (例如 Bazel SDK)。
  • 作業系統 (OS) 二進位檔，包括設定及組合 Fuuchsia 產品組合所需的核心、系統啟動載入程式、套件、工具和其他材料。
    • 一些預先組合的產品套裝組合 (例如 workbench 產品)1。
  • 其他各項構件，例如說明文件和 Fuchsia 相容性測試 (CTF) 版本。

沒有任何一個封存包含所有這些構件；不同的構件是由不同的建構工具產生，並上傳至不同的存放區。有些構件可以免費在線上取得，有些成果則是機密。(事實上，IDK 和 OS 二進位檔同時有公開和機密變化版本。)

這些團隊結合了：

  • 這些都是只以 Fuchsia 來源樹狀結構的單一修訂版本 (特別是 Google 內部版本的 integration.git2) 建構，且
  • 所有版本都會發布至相同的發布版本的存放區。

發布版本

「發布版本」是命名版本名稱的字元字串，

在 integration.git 的 Google 內部版本中，每個發布版本都有對應標記，但不可變更指向建構版本二進位檔成果的 Git 修訂版本。

版本名稱為 M.YYYYMMDD.R.C (例如 2.20210213.2.5)，其中

  • M 表示版本的「里程碑」。
  • YYYYMMDD 是版本記錄從 main 分支版本分隔的日期。
  • R 表示「發行」版本號碼。這個 Pod 會從 0 開始，如果在同一天建立多個版本，就會遞增。
  • C 表示「候選」版本號碼。這個指標從 1 開始，當里程碑版本分支對先前版本進行變更時，就會遞增。

Canary 版

一天數次3，系統會根據 Fuchsia 來源樹狀結構最後已知的良好修訂版本建立初期測試版本。具體而言，Git 標記會套用在 Google 內部 integration.git 版本中的該修訂版本，並觸發各種建構工具來建構並發布上述構件。初期測試版本不會取得自己的發布分支版本，只會取得標記。

每個初期測試版都僅支援短暫的期間，直到下一個初期測試版版本為止。錯誤修正不能在初期測試版中挑選。(換個方式說：初期測試版本的「候選」版本號碼一律應為「1」)。如果在初期測試版本中發現錯誤，系統會將該錯誤的修正項目套用至 Fuchsia 來源樹狀結構的 main 分支版本。受該錯誤影響的用戶端應復原至先前的版本，並/或等待包含修正項目的後續初期測試版。

因此，初期測試版適合用於開發和測試，但可能不適合用於實際工作環境。針對實際工作環境的用途，則建議使用里程碑版本。

里程碑版本

每隔幾週，就會使用 Google-internal 版本和 的 integration.git 公開鏡像，從現有「已知良好」項目的 git 修訂版本建立里程碑版本分支。源自里程碑版本分支版本的發布內容稱為「里程碑版本」或「穩定版」。

里程碑會依序編號，且在討論時通常會加上「F」前置字元 (如「F12 發布分支版本」)。

淘汰 FN 里程碑版本分支後，Fuchsia 來源樹狀結構中的主線開發就會繼續在 main 分支版本上運作，並邁入下一個 FN+1 版本，初期測試版本的版本將以 N+1 開頭，如下圖所示：

這張圖表上有代表 Fuchsia 里程碑的彩色箭頭。F11 先在 main 分支版本上開始分支，然後再將其設為 f11 分支版本。之後，主要分支版本會加上 F12 標籤，系統會再次執行分支等等。

里程碑版本會與初期測試版本共用其版本的 M.YYYYMMDD.R 部分，因此，從特定里程碑發布版本建構的版本之間，只有「候選」版本編號 C 會有所變更。請注意，這表示無論版本是初期測試版本或里程碑版本，都不一定能立即看出該版本 (但 C 的值大於 1 表示版本來自里程碑版本分支版本)。

與初期測試版本不同，里程碑版本在建立後經過數週支援。也就是說，您可以在剪下版本後，對里程碑版本分支進行改善。每次變更為里程碑發布分支版本後，系統都會以較大的「候選」版本號碼發布新的里程碑。

主要政策規範如下：

  • 功能是在 main 上開發，而不是在里程碑的版本分支中開發。
  • 對里程碑版本所做的變更會先套用至 main，然後再選取分支版本。
  • 只有修正錯誤 (與品質、安全性、隱私權、法規遵循等) 相關的變更才會發布至里程碑版本分支。我們不會進行相關變更，將新功能導入里程碑版本分支。

這些政策旨在盡可能降低里程碑版本分支帶來新錯誤的機率，因此與指定里程碑相關聯的版本穩定性和穩定性應該會隨著時間改善。因此，我們鼓勵下游客戶積極採用這些新的里程碑版本。

在某些特殊情況下，我們可能需要對這些政策進行偏離 (例如，可能需要在機密分支版本上開發安全性修正項目，才能避免在安全漏洞修正前公開發布安全漏洞)。是否要加入里程碑版本分支版本的變更，最終取決於版本管理員的決定。

回溯相容性

Fuchsia 專案承諾單一版本 (例如初期測試版本或里程碑) 中的所有構件都能彼此相容。舉例來說，如果開發人員使用 SDK 版本 2.20210213.2.5 建構元件，我們承諾該元件會在 OS 版本 2.20210213.2.5 的 Fuchsia 裝置上執行。如果元件在這些情況下發現 Fuchsia 平台出現錯誤行為，將會視為錯誤。

嚴格來說，根據本文所述，Fuchsia 並未針對「任何」兩個版本提供正式的 API 或 ABI 相容性保證，沒有任何現有的 RFC 討論相關事宜。但實際上，透過單一版本建立的 SDK 所建構的 Fuchsia 元件，經常根據不同的版本在 Fuchsia 系統上執行，而我們仍解決在這些設定中發現的問題。

我們將在日後的 RFC 中說明並修改各版本 API 和 ABI 相容性的條件保證。

文件記錄

  1. 其中部分產品是基於歷史原因而在 Fuchsia 來源樹狀結構中定義，因此會盡快從樹狀結構外移，來促進產品/平台區隔。 ↩

  2. 由於技術限制，這些標記只會出現在內部 integration.git 中。到了一天，我們可能也會開始在公開鏡像中發布這些標記。

  3. 這份文件未指定任何特定發布頻率。 時間範圍的名稱旨在提供不同程序頻率的「規模順序」預估值。行銷系列活動會隨著專案和客戶的需求不斷演進。 ↩