版本

Fuchsia「版本」是指在特定時間點，Fuchsia 專案產生的一組構件，並以特定「版本」名稱發布。每個 Fuchsia 版本都會實作一組 API 級別的 ABI，因此可以執行任何建構時間目標 API 級別位於該組的元件。

發行內容包括：

• 整合器開發套件 (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 有下列幾種發布類型：

• Canary 版
• 里程碑版本

初期測試版

系統每天會根據 Fuchsia 來源樹的最後一個已知良好修訂版本，建立幾次²初期測試版。具體來說，系統會在 Google 內部版本的 integration.git 中，將 Git 標記套用至該修訂版本，並觸發各種建構工具，建構及發布上述構件。Canary 版本不會有自己的發布分支，只有標記。

每個 Canary 版本僅在短時間內提供支援，直到下一個 Canary 版本發布為止。錯誤修正不會挑選到 Canary 版本。(換句話說，初期測試版本的「候選」版本號碼一律為「1」)。如果在 Canary 版中發現錯誤，系統會將該錯誤的修正套用至 Fuchsia 原始碼樹狀結構的 main 分支。受該錯誤影響的用戶端應復原至先前的版本，和/或等待後續的 Canary 版發布，其中包含修正程式。

因此，初期測試版本適合用於開發和測試，但不建議用於正式環境。建議您在實際作業環境中採用里程碑版本。

里程碑版本

每隔幾週，系統就會在 Google 內部版本和 integration.git 的公開鏡像中，從現有的「已知良好」Canary 版本 Git 提交開始，建立里程碑發布分支。從里程碑發布分支版本衍生的版本稱為「里程碑版本」或「穩定數字版本」。

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

FN 里程碑發布分支版本截斷後，Fuchsia 來源樹狀結構中的主線開發作業會繼續在 main 分支版本上進行，朝下一個 FN+1 版本邁進，而 Canary 版本則會以 N+1 開頭，如下圖所示：

里程碑版本與所依據的 Canary 版本共用版本號碼的 M.YYYYMMDD.R 部分，因此從特定里程碑版本分支建構的版本之間，只有「候選」版本號碼 C 會變更。請注意，這表示從版本中不一定能立即看出該版本是初期測試版還是里程碑版本 (不過，如果值大於 C，表示該版本來自里程碑版本分支)。

與 Canary 版本不同，里程碑版本在建立後會支援一段時間。也就是說，里程碑發布分支版本建立後，仍可進行改善。每次變更里程碑發布分支版本後，系統都會發布新的里程碑版本，並使用較大的「候選」版本號碼。

main正在開發

一般政策規定：

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

這些政策旨在盡量減少里程碑發布分支版本變更引入新錯誤的機率，因此與特定里程碑相關聯的發布版本可靠性和穩定性應會隨著時間改善。因此，我們建議下游客戶盡快採用這些新的里程碑版本。

在某些特殊情況下，我們可能需要偏離這些政策 (例如，可能需要在機密分支版本中開發安全性修正程式，以免在修正程式準備就緒前公開漏洞)。是否要在里程碑發布分支版本中納入變更，最終由發布管理員決定。