RFC-0227：Fuchsia 發布程序

摘要

這份 RFC 將現有的 Fuchsia 平台發布程序正式化。

在本 RFC 中，「發布」一詞是指產生及發布各種構件，供軟體供應鍊中更下游的開發人員 (例如元件作者或產品擁有者) 取用。不是指將更新內容提供給以 Fuchsia 為基礎的產品，供最終使用者使用。

提振精神

Fuchsia 已經有幾年的功能發布程序了。不過，雖然 Fuchsia 版本和里程碑版本分支可供外部觀察者查看，但尚未有 RFC 文件可說明並定義這項程序。

早期的 Fuchsia 版本需要與下游合作夥伴密切合作，但每個里程碑都比前一個里程碑更不特別，也更平淡。

為了讓這個趨勢持續朝成熟方向發展，每位 Fuchsia 開發人員都必須瞭解自己的角色，以免我們的版本破壞下游合作夥伴。因此，這份 RFC 將現有 Fuchsia 發布程序中，平台貢獻者最需要瞭解的部分加以編碼。

相關人員

協助人員：davemoore@google.com

審查者：

• billstevenson@google.com，發布計畫管理負責人
• abarth@google.com，相關 RFC-0002 作者
• atyfto@google.com，共同作者和基礎架構負責人

諮詢對象：aaronwood@google.com、chaselatta@google.com、sethladd@google.com

社會化：與專家討論，確認資料正確反映現實世界現況。

需求條件

本 RFC 說明目前的發布程序。但不會強制要求任何變更。

如上所述，本 RFC「不會」討論向最終使用者提供軟體的相關內容。本 RFC 所述的構件會交付給開發人員和產品擁有者。他們會使用這些構件來建構軟體，最終透過超出本 RFC 範圍的程序將軟體交付給使用者。

設計

Fuchsia release 是一組產生的構件，是 Fuchsia 專案在特定時間點的輸出內容，並以特定release version名稱發布。

其中包括：

• 整合器開發套件 (IDK)：一組小型程式庫、套件和工具，用於建構及執行以 Fuchsia 為目標的程式。
  • 許多以 IDK 為基礎的 SDK (例如 Bazel SDK)。
• 作業系統 (OS) 二進位檔，包括核心、系統啟動載入程式、套件、工具，以及設定和組合 Fuchsia 產品套件所需的其他元素。
  • 多個預先組合好的產品組合 (例如工作台產品)¹。
• 其他各種構件，例如文件和 Fuchsia (CTF) 相容性測試版本。

沒有任何一個封存區包含所有這些構件；不同的構建工具會產生不同的構件，並上傳至不同的存放區。部分構件可在網路上免費取得，其他則屬於機密資料。(事實上，IDK 和 OS 二進位檔都包含公開和機密的變化版本)。

這些元素的共同點如下：

• 這些測試套件都是從單一修訂版的 Fuchsia 來源樹狀結構 (具體來說，是 Google 內部版本的 integration.git²) 建構而成，
• 這些檔案都會發布至同一個發行版本下的各自存放區。

發布版本

版本號碼是用來命名版本的字元字串。

每個發布版本在 Google 內部版本的 integration.git 中都有對應的標記，該標記會不可變動地指向 Git 提交，而該提交是用來建構發布版本的二進位元構件。

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

• M 表示發布版本的「里程碑」。
• YYYYMMDD 是發布記錄與 main 分支版本分歧的日期。
• R 表示「發布」版本號碼。這個值從 0 開始，如果同一天建立多個版本，這個值會遞增。
• C 表示「候選」版本號碼。這個值從 1 開始，當里程碑版本分支中的先前版本有變更時，就會遞增。

初期測試版

每天幾次³，系統會根據 Fuchsia 來源樹狀結構的最後已知良好修訂版本，建立初期測試版。具體來說，Google 內部版本的 integration.git 會將 Git 代碼套用至該修訂版本，並觸發各種建構工具，以便建構及發布上述所述的構件。Canary 版本沒有專屬的版本分支，只有標記。

每個 Canary 版本都只支援短暫的時間，直到下一個 Canary 版本推出為止。並非所有錯誤修正都會納入 Canary 版本。(換句話說，初期測試版本的「候選」版本號碼應一律為「1」)。如果在測試版中發現錯誤，我們會將該錯誤的修正程式套用至 Fuchsia 來源樹狀結構的 main 分支。受該錯誤影響的用戶端應回溯至先前的版本，並/或等待後續包含修正程式的測試群組版本。

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

里程碑版本

每隔幾週，Google 內部版本和 integration.git 的公開鏡像都會建立里程碑版本分支，從現有「已知良好」的 Canary 版本 Git 提交開始。來自里程碑版本分支的版本稱為里程碑版本或穩定版本。

里程碑會依序編號，討論時通常會在前面加上「F」字樣 (例如「F12 發布分支」)。

一旦 FN 里程碑版本分支完成，Fuchsia 來源樹狀結構中的主開發作業就會在 main 分支中繼續進行，以便朝下一個 FN+1 版本邁進，而金絲雀版本將有以 N+1 開頭的版本，如以下圖表所示：

里程碑版本會與其所依據的測試版共用版本的 M.YYYYMMDD.R 部分，因此在從特定里程碑版本分支建立的版本之間，只有「候選」版本號碼 C 會有所變更。請注意，這表示從版本中無法立即判斷該版本是 Canary 版本還是里程碑版本 (雖然 C 值大於 1 表示版本來自里程碑版本分支)。

與 Canary 版本不同，里程碑版本在建立後的幾週內會提供支援。也就是說，在發布分支切割後，里程碑發布分支可能會進行改善。每次變更里程碑版本分支後，系統都會發布新的里程碑版本，並使用較大的「候選」版本號碼。

一般政策規定如下：

• 功能是在 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 獲得認可後，仍可繼續改進。

缺點、替代方案和未知事項

我們目前的版本命名方式無法清楚區分 Canary 版本和里程碑版本。里程碑版本看起來就像是經過大量精選的 Canary 版本。

版本號碼中出現 YYYYMMDD 的情況在軟體中相當罕見，可能會造成誤解。一般觀察者可能會認為這是版本或發布日期，較晚的版本會是「較新」的版本，但這不一定適用於里程碑版本。在某些情況下，13.20230801... 等版本可能會包含 14.20230910... 沒有的修補項目。

我們可以改用更接近語意化版本控制的版本命名架構，並在測試版中標示預先發布 ID。

同樣地，canary 和 milestone 這兩個詞彙也不是標準用語。比較常見的類似用詞是「預先發布」和「穩定」。

從技術層面來說，這些變更並不難以實施，因此我們或許會在後續 RFC 中改善這些項目。

既有技術與參考資料

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