RFC-0239：實際平台版本管理

RFC-0239：實際平台版本管理
狀態已接受
領域
  • 一般
  • 管理事宜
說明

概念模型和保證 Fuchsia 的相容性。
更小鳥
作者
審查人員
提交日期 (年月分)2023-11-08
審查日期 (年-月-日)2024-01-30

編輯這個 RFC

編輯 RFC 中繼資料

摘要

這個 RFC 的目標是依 RFC-0002、RFC-0083 等範圍擴大，達成下列目標：

  • 規劃一個概念模型 說明 Fuchsia 如何實際應用 API 級別和 ABI 修訂版本
  • 就這個概念模型中所述 提供 API 和 ABI 相容性保證
  • 概述我們計劃如何達成這些相容性保證。

簡要說明：

  • 每個 Fuchsia milestone 都會提供專屬的 API 級別。請將 API 級別 15 視為「Fushisia 平台介面的第 15 版，這是 F15 首次支援的版本」。
  • 每個 Fuchsia 版本都支援多個 API 級別。舉例來說，F15 里程碑版本支援 API 級別 11、12、13、14 和 15。
  • 開發人員在建構元件時，會選取單一「目標 API 級別」。指定 API 級別 13 的元件將在 API 級別 13 中看見 Fuchsia 平台介面如同之前，而且會在支援 API 級別 13 的任何 Fuchsia 系統上執行。
  • Fuchsia 核心和平台元件支援多個 API 級別，因此同時實作。

提振精神

如 RFC-0227 中所述， Fuchsia 平台版本的主要元件為：

  • 整合商開發套件 (IDK)：是一組程式庫、套件和工具，用於建構及執行指定 Fuchsia 的元件，
  • 作業系統 (OS) 二進位檔，包括核心、系統啟動載入程式、套件、工具，以及其他設定及組合 Fuuchsia 產品套件所需的材料。

IDK 是 Fuchsia SDK 各建構系統通用的先期，用於描述構成 Fuchsia 平台介面的 API 元素 (例如通訊協定、方法、欄位、引數、程式庫)，並允許最終開發人員編寫使用這些 API 元素的元件。IDK 中的部分介面是由 OS 二進位檔 (例如核心和平台元件) 實作，而其他介面則是由外部元件 (例如應用程式或驅動程式) 實作，並預期 OS 二進位檔會呼叫這些介面。

Fuchsia 平台介面仍在持續開發中，OS 二進位檔也會持續更新以配合使用。這些變更1會在下游流程中迅速提供給開發人員和產品擁有者。在 API 級別推出之前，IDK 只會包含平台介面的一則說明。星期一建構的 IDK 將描述 Fuchsia 平台介面與當週稍晚建構的 OS 實作的不同版本。這會造成問題：如果 FIDL 方法及其實作在星期三刪除，則使用週一的 IDK 建構的外部元件可能會嘗試呼叫該方法，但僅會通知週五的 OS 要求，該方法不存在。

理論上，我們可以嘗試禁止 IDK 和 OS 版本之間不一致。我們可能表明，OS 只會執行在完全相同的 Fuchsia 版本中，使用 IDK 建構的元件 (也就是說，OS 版本 2.20210213.2.5 只會執行使用 IDK 版本 2.20210213.2.5 建構的元件)。然而，我們無法要求開發人員在推出新版 Fuchsia 時持續更新及重建元件。因此，一般而言，建構外部元件的 IDK 和執行這些元件的 OS 可能來自不同的 Fuchsia 版本，甚至可能來自不同的里程碑。

此提示問題如下：在什麼情況下，使用從某版本 IDK 建構的元件可以在 OS 上順利執行？

RFC-0002 導入 API 級別和 ABI 修訂版本做為工具，以協助解答上述問題，但不太具體，也不清楚這些目標的實際使用方法，而且並未提供具體的相容性保證。這個 RFC 展示了 API 級別和 ABI 修訂版本在實作中的使用情況、建立相容性保證政策，並簡單討論遵守該政策的策略，藉此填補這些缺口。

相關人員

講師：jamesr@google.com

審查者：

  • abarth@google.com
  • ianloic@google.com
  • mkember@google.com
  • yaar@google.com

諮詢時間：

  • chaselatta@google.com
  • ddorwin@google.com
  • sethladd@google.com

社會化：

這個 RFC 中的模型與政策在過去幾年間以漸進方式建構，但目前尚未對任何 RFC 進行編碼。此特定提案透過許多文件和對話取得，在平台版本管理工作小組的成員之間主要發生這個問題。

假設

要說明公開 API 的元件與使用該 API 的另一個元件之間的相容性時，我們會假設互動的其中一端是建立「樹狀外」的外部元件 (亦即在 Fuchsia 平台建構作業之外，透過 IDK 建構)，而互動的另一端則是內建於 tree 的 Fuchsia 平台元件的 OS 二進位檔。定義版本管理做法和相容性「之間」外部元件互動的方式超出範圍，因此不適用於未來的工作。

設計

本節將說明 Fuchsia Platform 版本管理背後的概念模型。本文所述的許多概念先前已在 RFC-0002 中引入，但本文會提供更多具體細節和限制。

此「設計」部分的文字應提供豐富資訊，而非強制性內容。下方的政策變更一節會重複這段文字中任何部分代表現有政策的變更。

API 等級

Fuchsia 平台介面不斷變更，而新的 Fuchsia 版本每天會持續建立，而且一天會多次更新。我們不會推斷每個 Fuchsia 版本與其他版本中的 Fuchsia 平台介面的相容性，但這並不令人困擾，而是會考量到版本與有限 API 級別的相容性。

您可以將 API 級別想成構成 Fuchsia 平台介面的 API 的「版本」、「版本」或「快照」。API 級別 10 是「Fuchsia API 介面的第 10 版」。API 級別會與里程碑同步，因此 API 級別 10 也可以視為「F10 發布時的最新版 Fuchsia 平台介面」。

您可以使用 API 級別來建立陳述式，例如「fuchsia.lightsensor.LightSensorData FIDL 資料表在 API 級別 10 (rgbc、calculated_lux 和 correlated_color_temperature) 中有三個欄位，但 API 級別 11 (si_rgbc 和 is_calibrated) 新增了兩個欄位。由於 API 級別 11，其中有五個欄位，但我們可能會移除部分或新增更多 API 級別 16。

如同教科書版本，API 級別「不可變更」。教科書的內容可能會隨時間改變，但教科書第 2 版的內容在第 2 版發布後永遠不會變更。也就是說，凡是已知特定 API 級別的兩個 Fuchsia 版本，都會對構成該 API 級別的 API 元素組合達成共識。

Fuchsia 平台介面不僅限於 FIDL，還包含系統呼叫、C++ 程式庫和其中的方法、永久檔案格式等。從概念上來說，這些都是依 API 級別設定版本，但實際上，FIDL 程式庫的版本管理支援遠遠高於 Fuchsia 平台介面的其他層面。

指定 API 級別

開發人員在建構元件時，會選取單一「目標 API 級別」。如果開發人員指定 API 級別 11，其元件將能完全存取 API 級別 11 中提供的 API 元素。如果方法已在 API 級別 12 中新增，元件不會在產生的繫結中看到該方法。反之，如果在 API 級別 12 中「移除」API 級別 11 的方法，該元件「將可」繼續使用該方法。

在建構元件的過程中，IDK 中的工具會將目標 API 級別的相關 ABI 修訂版本嵌入元件的套件中。這通常稱為元件的「ABI 修訂版本戳記」。

透過 ABI 修訂版本戳記，我們可確保元件觀察到的執行階段行為會與目標 API 級別指定的行為相符。目前，ABI 修訂版本戳記的用途非常不精確：如果 OS 支援 ABI 修訂版本的對應 API 級別，元件就可以執行。否則 (舉例來說，如果外部元件指定 API 級別 11，但 OS 二進位檔不再實作 API 級別 11 中的方法)，元件管理服務就無法啟動元件。

版本和階段

每個 Fuchsia 版本都支援多個 API 級別，並為每個 API 級別指派「階段」。您可以在 Fuchsia 版本中下載 IDK，並在 version_history.json 檔案中查看 API 級別。

舉例來說，假設的 Fuchsia 版本 20.20240203.2.1 可能包含：

  • 「支援」階段中的 API 級別 17、18 和 19。也就是說，IDK 版本 20.20240203.2.1 可以建構指定任何 API 級別的元件，而 Fuuchsia 版本 20.20240203.2.1 可以執行指定任何這些 API 級別的元件。大多數的開發人員應盡量指定支援的 API 級別。
  • 處於「停用」階段的 API 級別 15 和 16。Fuchsia 仍會「執行」run目標停用 API 級別的元件，但 IDK 不再支援在建構元件時指定這些元件。

這個假設的 version_history.json 還會列出 API 級別 14 及較舊版本的「已淘汰」階段。Fuchsia 不會針對已淘汰的 API 級別建構或執行元件，但會在發布後保留。

API 級別會在支援的階段發布，不久後其對應的里程碑分支版本遭到截斷。上述假設的 20.20240203.2.1 初期測試版本來自 API 級別 20 發布之前，因此 API 級別 20 並不明確。在 F20 分支版本剪下前，API 級別 20 會發布，後續版本 (例如 20.20240301.4.1) 則會將 API 級別 20 列為「支援」。特別要注意的是，所有「milestone」版本都會在支援階段中加入對應的 API 級別。

當選擇停止支援 API 級別時，我們會先將其移至服務終止階段。這樣做會產生一連串的排序：指定 API 級別的現有二進位檔，但是不會建立指定該 API 級別的新二進位檔 (至少不會建立指定該 API 級別的新二進位檔)。一旦所有指定特定 API 級別的現有二進位檔都遭到淘汰，我們就能將其淘汰。

API 級別不會依特定時程停用或淘汰。一旦合作夥伴不再依據該 API 級別建構該級別，我們就會停用該 API 級別，一旦我們的合作夥伴不想再執行指定該 API 的二進位檔，我們就會淘汰該級別。鑒於合作夥伴人數持續成長，我們不太重視他們個別的需求，因此我們目前需要製定更正式的政策，但目前做法就先這麼做。

NEXT 和 HEAD 虛擬 API 級別

除了上述的 API 級別以外，還有兩種特殊的「可變動」虛擬 API 級別：NEXT 和 HEAD。

與其他 API 級別不同，NEXT 和 HEAD 的內容可在發布到發布的過程中任意變更。您可以新增、修改、取代、淘汰和/或移除 API 元素原則上，20.20240203.1.1 中的 NEXT 和 20.20240203.2.1 中的 NEXT 看起來可能完全不同，不過實際上，變更會逐漸增加。

如 RFC-0083 HEAD 所述，代表開發的出血邊緣，適用於樹狀用戶端 (例如其他平台元件或整合測試) 而沒有穩定性問題。HEAD 中導入的 API 元素可能甚至無法運作。例如，方法可能已新增至 HEAD 的通訊協定，但通訊協定伺服器可能尚未實際實作該方法。

NEXT 代表下一個編號 API 級別的「草稿」版本。在每個里程碑分支版本中，我們很快都會發布 NEXT 的內容做為新的 API 級別。其實，我們會建立變更清單，將 FIDL 註解和 C 預先處理工具巨集中的 NEXT 例項替換為下一個里程碑分支版本的特定編號。NEXT 中的 API 元素應可正常運作，且「不穩定」會在發布下一個 API 級別前進行變更，但您仍可進行變更。

在 RFC-0083 的語言中，HEAD 比 NEXT 新，也就是說，NEXT 中的所有 API 變更也都會納入 HEAD。

開發人員可指定 HEAD 或 NEXT，但這樣做會失去 API 和 ABI 相容性保證。請參閱說明這些保證的章節，進一步瞭解在樹狀結構外指定 NEXT 或 HEAD 的影響。

政策異動

本節列出此 RFC 提議的特定政策變更。

模型變更

此 RFC 會對平台版本管理模型進行下列變更：

  • 編號的 API 級別現在無法變更。這項屬性在所有 API 級別 (特殊的「開發中」API 級別除外) 中已採用此屬性。此 RFC 實際上會淘汰「開發中」API 級別，並改用 NEXT。
  • 導入 API 級別階段。實務中已有「支援」和「已淘汰」，但後者目前稱為「不支援」。此 RFC 建議重新命名並新增「日落」。
  • 推出 NEXT。這是另一個特殊 API 級別，例如 HEAD。HEAD 為「較新」NEXT。這會取代目前將最新 API 級別指定為「開發中」API 級別的做法。
  • 允許對 NEXT 進行回溯不相容的變更。目前的政策是透過工具強制執行，但並非在任何 RFC 中製定，是只有開發中的 API 級別能夠進行回溯相容的變更。這個 RFC 會移除該限制，且不會套用到 NEXT。詳情請參閱下文。
  • 搭配使用 API 級別與里程碑。系統會根據 NEXT 的內容，在 FN 里程碑分支版本結束前，不久建立 API 級別 N。這在實際應用中為真，但尚未在任何 RFC 中修正。
  • 如果合作夥伴允許，API 級別會快速分階段。一旦所有合作夥伴不需要建構以該級別為目標的二進位檔，我們就會立即停用支援的 API 級別，而且也很快就會停用。我們即將淘汰停用 API 級別，因為所有合作夥伴都不希望在新的 Fuchsia 版本中執行任何指定該層級的二進位檔，而且也要盡早取消。

API 相容性保證

Fuchsia 現在針對編號 API 級別提供下列 API (也就是建構時間) 相容性保證 (須遵守以下注意事項)：

如果最終開發人員可以使用 IDK 的「部分」版本，成功建構指定編號 API 級別 N 的元件，就能在支援的階段使用 N 的「任何」IDK 版本，成功建構相同的原始碼。

換句話說，在所選目標 API 級別停用前，開發人員可以放心地在不破壞建構作業的情況下升級或復原 IDK。如果在未變更目標 API 級別的情況下更新至其他 IDK，會導致建構作業中斷 (例如，如果原本使用的 API 元素已不存在)，系統就會視為 Fuchsia 平台錯誤。

另一方面，沒有可變動的虛擬 API 級別 NEXT 和 HEAD 的 API 相容性保證。指定 NEXT 或 HEAD 時，端開發人員可能會發現更新 IDK 會導致程式碼無法再編譯。

具體而言，目前的合作夥伴會與 Fuchsia 團隊密切合作，我們會避免破壞指定 NEXT 的終端開發人員版本。我們會盡量輕鬆避免破壞以 HEAD 為目標的端對端開發人員版本。

ABI 相容性保證

Fuchsia 現在可針對編號 API 級別提供下列 ABI (也就是執行階段) 相容性保證 (必須遵守下列注意事項)：

在支援或停用階段，指定編號 API 級別 N 的元件會在包含 N 的任何 Fuchsia 版本中順利執行，且在發布版本之間不會出現任何不當行為變更。

換句話說，最終開發人員不需要變更或重新編譯程式碼，就能在較新版本的 Fuchsia 上執行，直到選擇的目標 API 級別淘汰為止。如果平台的行為不同，會幹擾其元件在其他版本的 Fuchsia 中運作，則會視為 Fuchsia 平台錯誤。

另一方面，針對指定可變動 API 級別 NEXT 或 HEAD 的元件，我們「不」保證具有 ABI 相容性。只有在執行 Fuchsia 的 Fuchsia 版本「完全」與建構該元件的 IDK 版本相同時，系統才會允許執行以 NEXT 或 HEAD 建構的元件。舉例來說，指定使用 IDK 版本 16.20231103.1.1 建構的 NEXT 元件會在 Fuchsia 版本 16.20231103.1.1 上執行，但「不會」(預設) 在搭載 Fuchsia 版本 16.20231103.2.1 的裝置上執行。

在大多數情況下，確保建構元件的 IDK 版本與執行該元件的 OS 版本完全相同。值得注意的是，整合測試和本機實驗是值得注意的例外情況。樹狀結構外存放區通常可以控管用於編譯的 IDK 版本，以及用於測試的 OS 版本。如果他們想測試 NEXT 或 HEAD 中的功能，則應讓這兩項功能保持同步。

不支援的設定

根據預設，component_manager 會拒絕啟動 ABI 修訂戳記表示不在 ABI 相容性保證涵蓋範圍內的元件。具體違規事項如下：

  • 特定 Fuchsia 版本只會在該版本開始支援或停用 N 時，執行指定 API 級別 N 的元件。
  • 特定 Fuchsia 版本只有在使用相同版本 IDK 建構的 Fuchsia 元件時，才會執行指定 NEXT 或 HEAD 的元件。

同樣地，產品組件也會拒絕使用與平台不相容的元件組合產品。

產品負責人可選擇性停用這些檢查功能。舉例來說，他們可以將個別元件加入許可清單，使其指定 NEXT 或 HEAD，即使建構的 IDK 來自不同的 Fuchsia 版本。產品負責人停用了這些檢查功能，但必須自行承擔風險。

實作

如要實作這些檢查，您需要變更 ABI 修訂版本戳記。這些變更的完整設計不在此 RFC 的範圍之內，但簡單來說：

  • 和目前的情況一樣，系統會在每個 API 級別發布時指派專屬的 ABI 修訂版本。指定編號 API 級別的元件會加註該 API 級別的對應 ABI 修訂版本。
  • 此外，系統會為每個版本指派專屬的 ABI 修訂版本。針對 HEAD 或 NEXT 的元件，會標上這個個別版本的 ABI 修訂版本。

特定版本的 OS 二進位檔會包含在支援或停用階段中所有 API 級別的 ABI 修訂版本清單，以及該版本的 ABI 修訂版本。根據預設，只有具備其中一個 ABI 修訂版本的元件才能執行。

日後推出的擴充功能

請注意，「每個 API 級別各有一個 ABI 修訂版本，再加上 NEXT/HEAD 範圍的一個 ABI 修訂版本，不一定是這個設計中的最後一個字詞。ABI 修訂版本是我們以機器可讀取的方式將 ABI 相容性保證編碼的方式，因此如果保證內容將更加精細，所以也必須分配 ABI 修訂版本。

舉例來說，假設我們將 API 介面的一部分指定為「長期支援 (LTS)」，而且在 API 級別中繼續支援該 API 級別的 LTS API。假想的 F30 版本可能支援 API 級別 25 的 LTS API，但不支援非 LTS API。該版本能夠執行僅使用 LTS API 的指定 API 級別 25 的元件，但無法執行以 API 級別 25 為目標的元件。因此，這兩種元件都需要加上不同的 ABI 修訂版本，因此我們可以提供每個 (API 級別、LTS 狀態) 組合各自的 ABI 修訂版本。

我們掌握了這些線條的想法，如果選擇探索，會在後續的 RFC 中說明這些概念。

平台元件同時支援所有支援的 API 級別

由於我們目前沒有平台元件可根據連線另一端元件的 ABI 修訂版本戳記來修改其行為的機制，因此支援多個 API 級別意味著「同時」支援多個 API 級別。平台元件的行為必須符合支援或停用階段中各 API 級別的規格。

更明確地說，平台元件「不得」假設外部元件針對 API 級別的任何相關資訊，除非其指定目標為支援或停用的 API 級別。

舉例來說，如果 Foo 方法已從 API 級別 15 的 FIDL 通訊協定中移除 (也就是使用 @available(added=A, removed=15) 註解)，但 API 級別 14 仍支援，但實作相關通訊協定伺服器的平台元件「必須」繼續實作 Foo，直到包含該通訊協定伺服器的所有 API 級別已淘汰為止。Foo

相反地，如果該 FIDL 通訊協定伺服器是由樹狀結構外驅動程式庫實作，則無論驅動程式庫是否實作 Foo，與該驅動程式庫通訊的平台元件都必須正常運作。

此策略不僅限制了平台元件的實作，也限制了我們可以對平台介面進行的任何修改。理論上，API 可能會任意從 API 級別變更為 API 級別，但實際來說，有些變更 (例如重複使用 FIDL 通訊協定方法的結構) 導致我們無法與指定不同 API 級別的外部元件正確通訊，卻無法取得更多資訊。

我們可能會針對支援多個 API 級別制定不同的策略，但這是未來工作領域。

注意事項

API 和 ABI 相容性保證設有幾點注意事項。

「保證」的意義

「保證」相容性並不表示 Fuchsia 絕對不會破壞我們的整體相容性保證，說不定的是人類。也就是說，當我們根據上述條款破壞相容性時，就會視為錯誤。我們會負責在內部修正這個情況，除了回報錯誤之外，開發人員不需要採取任何行動。

撤銷保證

如果開發人員「做奇怪事」，則不適用 API 和 ABI。不當的導入方式包括但不限於：

  • 修改自己的 IDK 副本
  • 存取內部命名空間中的成員
  • 手動合成要由 IDK 中的程式庫建構的資料。
  • 將不同 IDK 建構的共用程式庫連結到單一二進位檔。
  • 依此類推

作為一個值得注意的計數器範例，根據 Fuchsia 中的錯誤行為而「不會」計為「做怪事」。在某些不幸的情況下，fixing錯誤可能會計為「不當行為變更」。詳情請參閱「不當內容異動」。

針對禁止行為的完整說明不在此 RFC 的涵蓋範圍內。在 Jacobellis v. Ohio 中， 將美國最高法院法官司法特斯

不當變更

根據 ABI 相容性保證，元件在支援元件目標 API 級別的 Fuchsia 版本之間，不會出現「不當行為變更」。「不當」的定義明顯主觀，有些變更可能會對其他人造成反感 (相關的 xkcd)。最後，需要處理不當行為變更的報告時，必須逐一處理。

安全性和隱私權

如果系統發現 Fuchsia 平台介面的特定部分存在重大安全性或隱私權問題，我們可能會視情況捨棄違規功能的支援，以滿足我們的安全性和隱私權目標。

效能

維持與舊版 API 級別的回溯相容性，會導致效能降低。如果沒有，系統會保留更多邏輯，以便回溯相容的平台二進位檔。就某些層面而言，這種情況是不可避免的，然而，API 級別淘汰的可能是加劇了這個問題。

回溯相容性

整個 RFC 從回溯與前瞻性都涉及到相容性問題。

測試

進行測試以確保 API 和 ABI 相容性是另一個大主題。

Fuchsia (CTF) 的相容性測試旨在提供測試涵蓋範圍，確認我們符合 ABI 的相容性保證。目前涵蓋率偏低 但目前仍在積極處理

目前，我們無法撰寫測試來驗證 API 相容性保證；所有樹狀結構內測試都是根據 LEGACY API 級別建構，因此無法複製指定編號 API 級別的顧客樹狀結構外體驗。必須著手處理，但不應禁止接受此 RFC。

說明文件

此 RFC 一經擴增，將重複使用其中的文字，做為 Fuchsia 平台開發人員針對多份文件的基礎：

此外，說明文件也需要更新，以反映現有概念的重新命名。

缺點、替代項目和未知

缺點：API 級別皆為不可分割的

如 RFC-0002 所示，API 級別涵蓋整個 Fuchsia 平台介面。因此，變更 API 級別階段 (例如停用 API 級別) 會影響整個 API 級別；我們無法只淘汰部分功能的子集。同樣地，最終開發人員鎖定的 API 級別也會鎖定整個 Fuchsia 平台介面；舉例來說，對大多數 API 而言，目標 API 級別是 13，單一特定 API 的 API 級別則為 16。

平台版本管理模型的日後擴充功能或許能包含有意義的子群組，但在 IDK 中，不同程式庫之間的依附元件則會導致這個問題。

替代做法：無日落階段

此 RFC 的早期草稿省略了日落階段，留下了「可能的未來工作」。終止階段是模型的合理延伸，也是在討論中主動引入，且主動納入這個階段似乎是合理的。

替代做法：其他可能的虛擬 API 級別

如上所述，HEAD 有許多可能的用途，例如樹狀元件之間的通訊、向整合測試公開的 API、實驗性 API 等等。實際上，這些用途實際上應該以不同的虛擬 API 級別表示嗎？

這個 RFC 建議從 NEXT 和 HEAD 開始，但在指派數值時留下缺口。如此一來，如果找到更多虛擬 API 級別，則可以新增更多虛擬 API 級別。

替代選項：回溯相容的開發 API 級別

Fuchsia 的子產品版本管理政策目前指出，只有回溯相容的變更可以透過開發中的 API 級別進行。此 RFC 復原該政策，因此，當端開發人員鎖定 NEXT 時，無法保證不同版本的 IDK 和 OS 二進位檔之間的相容性。

如果我們在開發 API 級別 (或 NEXT) 內維持這項回溯相容性政策，可進一步改善以下情況：只要 OS 二進位檔來自於 IDK 的較新版本，我們可保證 IDK 和 OS 二進位檔能夠相容。直到近期，我們將下游存放區移至支援的 API 級別時，才依賴這個屬性。

這有益於開發人員將新的 Fuchsia 功能加入開發中的 API 級別後，即可放心啟動該功能，無須等待該 API 級別發布。

然而，這會為系統帶來相當大的複雜性：

  • Fuchsia 平台開發人員不僅要維持與之前 API 級別 (已在 FIDL 和標頭檔案本身編碼的 API 簽名) 的回溯相容性，也必須與之前開發的 API 級別 (不支援) 的先前版本。如要查看這些舊版本，唯一的方法是檢查 Git 記錄，但實際上並不會如此。
  • 由於我們必須從平台移除功能，因此可能必須「部分」API 級別支援回溯不相容的變更。這表示 Fuchsia 平台開發人員必須在開發 API 級別「之後」，對編號 API 級別做出回溯不相容的變更。因此，在開發 API 級別方面實際上有「兩個」級別，Fchsia 平台開發人員需要解決這兩個級別。
  • 這使得 ABI 修訂版本大幅增加。為了支援開發 API 級別中回溯相容的變更，我們需要無限期保留個別版本的 ABI 修訂版本 (每天會建立數次)。OS 二進位檔需要針對各版本的 ABI 修訂版本支援 ABI 修訂版本，其中其中一個支援的 API 級別為開發中的 API 級別，以及根據目前里程碑孤立版本發布的所有 ABI 修訂版本。在目前的發布頻率中，這會為每個 API 級別加上約 168 個 ABI 戳記，而截至本文所述， Fuchsia 的版本必須支援超過 800 個 ABI 印章。雖然這類解決方案的記憶體成本可能不大，但目前要維持與數百、數千或數萬個不同 ABI 的相容性似乎不值得，尤其因為目前還沒有客戶使用開發中的 API 級別。

但日後可能會有額外的相容性保證。

替代做法：將 API 級別與里程碑分離

此 RFC 會明確地將 API 級別與里程碑編號相互連結。但這並非必要的，尤其是 Android 會將兩者分離。Android 專案會利用此能力發布 API 變更，並與作業系統的次要版本一併發布。舉例來說，API 級別 24 對應至 Android 7.0，API 級別 25 對應至 Android 7.1。

我在研究時找不到其他選擇遵循這個路徑的平台範例。我發現的其他平台在發布版本中說明 API 元素是否可用，例如「自 Chrome 88 起開放使用」或「iOS 6.1 已淘汰」。

macOS 和 iOS API 級別會與版本配置配置結合，但與 Fuchsia 不同的是，這兩個 API 級別都允許小幅修訂版本進行 API 變更。不過，這似乎是因為想將發布版本的主要版本與年度結合，同時仍允許 API 更新一年發布多次，這似乎是較吸引人的意願。

在 Chrome 推出之後，Fusisia 里程碑的模擬方式更為精準，且經常會遞增主要版本，而不使用子版本。如果我們希望更頻繁地穩定 API 級別，可以更頻繁地增加 Fuchsia 的里程碑數量。

替代選項：編號的「開發中」API 級別

這個 RFC 的早期草稿與目前實作的平台版本管理模式更為接近。在這個模型中，NEXT 不存在，而且最大數量的 API 級別可變動且稱為「開發中」API 級別。

理論上，這兩類模型之間還是有些微差異：

  1. 目前 Fuchsia 平台開發人員選擇要以哪個 API 級別推出功能。實作這個 RFC 後，程式碼將對 NEXT 進行實際工作環境限定的 API 變更，並會自動發布至下一個編號的 API 級別。
  2. 目前，以開發中的 API 級別為目標的開發人員在發布後會自動轉換為指定該 API 級別的支援版本。導入這個 RFC 後，就可以繼續鎖定 NEXT。

這兩個差異似乎不是非常正面或負面。

相較於開發中的 API 級別，NEXT 的主要優點在於溝通便利。此 RFC 的早期草稿採用動詞體操，以表示相容性保證：「在支援階段中，支援 API 級別 N 的任何 Fuchsia 版本建構的元件建構指定目標時，N 將能順利執行。」在目前的提案中，所有參與方都會同意指定 API 級別的內容，不需要限定詞。

替代做法：不要移除內容

我們可以完全禁止回溯不相容的變更，簡化平台版本管理作業。每個 API 級別都會支援舊版的所有功能，而「平台支援所有 API 級別」的屬性則會因支援最新的 API 級別而「免費提供」。

許多平台 (包括 Windows 和 Android) 大部分都採取這種方法，但因此無法從舊版 API 介面的舊版本中清除瑕疵。

雖然 Fuchsia 平台工程師需要繼續支援，只要這些 API 是在受支援的 API 級別或停用的 API 級別中，終端開發人員只需擔心所選目標 API 級別的內容，也不需要查看這類憑證。

不僅如此，「不要移除內容」可能使版本管理更簡單，但沒有任何方法能完全解決問題。開發人員仍需根據預期安裝數中最舊的 Fuchsia 平台版本，判斷要指定的 API 級別。

  1. 我們大部分的下游合作夥伴目前都仰賴 Fuchsia 的初期測試版本，而這些版本每天都會產生多次。在未來，更多合作夥伴會使用里程碑發布分支版本的 IDK 和 OS 二進位檔，但目前我們重視這個排列組合允許的立即回饋。 ↩