RFC-0227：Fuchsia 發布程序

RFC-0227： Fuchsia 發布程序
狀態	已接受
區域	開發人員 軟體組件
說明	說明 Fuchsia 的 SDK 和 OS 發布程序
問題
變更	119
作者	hjfreyer@google.com atyfto@google.com
審查人員	billstevenson@google.com abarth@google.com atyfto@google.com
提交日期 (年/月)	2023-08-14
審查日期 (年/月)	2023-10-02

摘要

這個 RFC 可標準化 Fuchsia 平台發布時的現有程序，

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

提振精神

Fuchsia 目前已有數年的時間推出功能發布程序。不過，雖然觀測器外部可查看 Fuchsia 版本和里程碑版本分支，但還沒有 RFC 文件和定義這項程序的定義。

早期 Fuchsia 版本與下游合作夥伴密切進行協調，但每個通過的里程碑都沒有什麼特別且難以處理。

為了延續這股趨勢，每位 Fuchsia 開發人員都需要瞭解自己在防止發布版本合作夥伴之間扮演的角色。因此，這個 RFC 會統一現有 Fuchsia 發布程序中最重要的部分，讓平台貢獻者瞭解。

相關人員

講師：davemoore@google.com

審查者：

• billingstevenson@google.com，發布計畫管理主管
• abarth@google.com，相關 RFC-0002 的作者
• atyfto@google.com、co-author 和 infra 負責人

顧問：aaronwood@google.com、chaselatta@google.com、sethladd@google.com

社交化：接受專家意見，確認內容如實反映世界的現況。

相關規定

本 RFC 說明瞭目前的發布程序。不會套用到任何變更。

如上所述，這項 RFC「不會」討論向使用者推送軟體的行為。本 RFC 所述的構件會傳送給開發人員和產品擁有者。他們會使用這些構件建構軟體，其最終會透過超出此 RFC 範圍的程序提供給使用者。

設計

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

內容如下：

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

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

這些團隊結合了：

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

發布版本

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

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

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

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

Canary 版

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

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

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

里程碑版本

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

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

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

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

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

主要政策規範如下：

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

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

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

實作

本 RFC 不會對 Fuchsia 發布程序進行任何變更。

回溯相容性

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

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

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

說明文件

這個 RFC 的大部分內容都會複製到個別文件，以便在 RFC 經過壓縮後繼續發展。

缺點、替代方案和未知

現行的版本命名配置在初期測試版本和里程碑版本之間沒有明顯區別。里程碑版本看起來就像初期測試版本，會套用許多櫻桃。

版本編號中存在 YYYYMMDD 在軟體中不重複，且可能誤導使用者。休閒觀察器可能會認為這是建構或發布日期，因為後期的建構作業「較新」，但這並不適用於里程碑版本。在某些情況下，13.20230801... 這類發布版本可能包含 14.20230910... 並未挑選的特定修正項目。

我們可以改用更接近「語意版本管理」的版本命名配置，初期測試版本會以預先發布版 ID 標示。

同理，「初期測試」和「里程碑」的字詞也不符合標準。其他類似的常見字詞可能包括預覽和穩定版。

就技術層面而言，這些變更不會相當困難，因此在後續的 RFC 中，我們希望改善這些功能。

先前的圖片和參考資料

• Chromium 發布版本和版本號碼。
• semver.org