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

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

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

編輯這份 RFC

編輯 RFC 中繼資料

摘要

本 RFC 的目標是擴充 RFC-0002、RFC-0083 等，方法如下：

  • 為 API 級別和 ABI 修訂版本在 Fuchsia 上的實際使用方式，制定概念模型，
  • 以概念模型為基礎，向合作夥伴提供 API 和 ABI 相容性保證，以及
  • 說明我們打算如何達成這些相容性保證。

簡要來說：

  • 每個 Fuchsia 里程碑都有對應的 API 級別。API 級別 15 可視為「Fuchsia 平台介面的第 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) 二進位檔，包括核心、系統啟動載入程式、套件、工具，以及設定和組裝 Fuchsia 產品組合所需的其他要素。

IDK 是 Fuchsia SDK 的前身，與建構系統無關，主要用於說明構成 Fuchsia 平台介面的 API 元素 (例如通訊協定、方法、欄位、引數、程式庫)，並讓開發人員編寫使用這些 API 元素的元件。IDK 中的部分介面是由核心和平台元件等 OS 二進位檔實作，其他介面則是由外部元件 (例如應用程式或驅動程式) 實作，並預期 OS 二進位檔會呼叫這些介面。

Fuchsia 平台介面持續開發中，作業系統二進位檔也會不斷更新以配合。這些變更會快速1 下游傳送給開發人員和產品擁有者。在導入 API 級別之前，IDK 只包含平台介面的單一說明。週一建構的 IDK 所述的 Fuchsia 平台介面版本，會與當週週五建構的 OS 實作版本不同。這過去會造成問題：如果 FIDL 方法及其實作項目在星期三遭到刪除，使用星期一 IDK 建構的外部元件可能會嘗試呼叫該方法，但星期五的 OS 會告知該方法不存在。

從簡單的角度來看，我們可以嘗試禁止 IDK 和 OS 版本不符的情況。可以說，OS 只會執行使用完全相同 Fuchsia 版本 (也就是 OS 版本 2.20210213.2.5 只會執行使用 IDK 版本 2.20210213.2.5 建構的元件) 的 IDK 建構的元件。不過，這並不可行，因為我們無法要求終端開發人員在發布新版 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 的另一個元件之間的相容性時，我們假設互動的一方是樹狀結構外建構的外部元件 (也就是透過 IDK 在 Fuchsia 平台建構外建構)，互動的另一方則是樹狀結構內建構的 OS 二進位檔，例如核心或 Fuchsia 平台元件 (也就是在 Fuchsia 平台的 GN 建構圖中建構)。定義外部元件之間互動的版本控管做法和相容性不在範圍內，留待日後處理。

設計

本節將說明 Fuchsia 平台版本控管背後的概念模型。本文介紹的許多概念先前已在 RFC-0002 中說明，但本文會提供更具體的詳細資料和限制。

「設計」一節的文字僅供參考，不具規範效力。下方的「政策異動」部分會重複顯示本文中代表現有政策異動的部分。

API 等級

Fuchsia 平台介面不斷變化，且每天都會多次建立新的 Fuchsia 版本。我們不會針對每個 Fuchsia 版本與 Fuchsia 平台介面的相容性進行推論，而是考量版本與有限數量的 API 級別相容性。

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

您可以使用 API 級別來陳述，例如「API 級別 10 (rgbc、calculated_lux 和 correlated_color_temperature) 的 FIDL 表格有三個欄位，但 API 級別 11 (si_rgbc 和 is_calibrated) 又新增了兩個欄位。自 API 級別 11 起，表格就一直有五個欄位，但我們可能會在 API 級別 16 中移除或新增欄位。」fuchsia.lightsensor.LightSensorData

如同教科書版本，API 級別是不可變更的。教科書內容可能會隨時間變更，但第 2 版教科書一經發布，內容就不會再變動。也就是說，任何兩個瞭解指定 API 級別的 Fuchsia 版本，都會同意構成該 API 級別的 API 元素集。

Fuchsia 平台介面不限於 FIDL，也包含系統呼叫、C++ 程式庫和其中的方法、永久檔案格式等。從概念上來說，這些項目都是依據 API 級別進行版本控管，但實際上，FIDL 程式庫的版本控管支援比 Fuchsia 平台介面的其他方面更進步。

指定 API 級別

建構元件時，終端開發人員會選取單一目標 API 級別。如果開發人員以 API 級別 11 為目標，元件將只能存取 API 級別 11 中提供的 API 元素。如果方法是在 API 級別 12 中新增，元件就不會在產生的繫結中看到該方法。反之，如果 API 級別 11 的方法在 API 級別 12 中移除，元件仍可繼續使用。

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

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

版本和階段

每個 Fuchsia 版本都支援多個 API 級別，並為每個 API 級別指派階段。如要查看 Fuchsia 版本中的 API 級別，請下載 IDK 並查看 version_history.json 檔案。

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

  • 支援階段的 API 級別 17、18 和 19。也就是說，IDK 版本 20.20240203.2.1 可以建構以任何這些 API 級別為目標的元件，而 Fuchsia 版本 20.20240203.2.1 可以執行以任何這些 API 級別為目標的元件。大多數終端開發人員應以支援的 API 級別為目標。
  • API 級別 15 和 16 處於淘汰階段。Fuchsia 仍會執行以淘汰 API 級別為目標的元件，但 IDK 不再支援在建構元件時以這些元件為目標。

這個假設的 version_history.json 也會在「已淘汰」階段列出 API 級別 14 和更早的版本。Fuchsia 不會建構或執行以已淘汰 API 級別為目標的元件，但會保留這些元件以供後代參考。

API 級別會在支援階段發布，時間點是相應里程碑分支版本發布前不久。上述假設的 20.20240203.2.1 Canary 版發布時間早於 API 級別 20，因此 API 級別 20 顯然不在其中。在 F20 分支版本發布前不久，API 級別 20 會發布，後續版本 (例如 20.20240301.4.1) 會將 API 級別 20 列為「支援」。具體來說，所有里程碑版本都會在支援階段中，包含對應的 API 級別。

如果我們選擇停止支援某個 API 級別，會先將其移至淘汰階段。這會建立某種後擋板，以確保指定該 API 級別的現有二進位檔繼續執行，但不會建立指定該 API 級別的新二進位檔 (至少不會透過新版 IDK 建立)。一旦以特定 API 級別為目標的所有現有二進位檔都已淘汰，我們就能停用該級別。

API 級別不會在特定時間停止支援或淘汰。而是會在合作夥伴不再使用該 API 級別建構應用程式時停止支援，並在合作夥伴不再想執行以該 API 級別為目標的二進位檔時淘汰。日後隨著合作夥伴數量增加，我們對個別需求的掌握度降低，屆時就需要更正式的政策，但目前這樣就夠了。

NEXT 和 HEAD 虛擬 API 級別

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

與其他 API 級別不同，NEXT 和 HEAD 的內容可能會在各個版本中任意變更。API 元素可能會新增、修改、取代、淘汰及/或移除。原則上，NEXT 中的 20.20240203.1.1 可能與 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 新，也就是說，HEAD 也包含 NEXT 的所有 API 變更。

終端開發人員可以指定 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 級別與里程碑配對。API 層級 N 會在 FN 里程碑分支版本截斷前不久，根據 NEXT 的內容建立。這在實務上確實如此，但尚未在任何 RFC 中獲得批准。
  • API 級別的階段進展速度取決於合作夥伴。只要沒有合作夥伴需要建構以支援的 API 級別為目標的二進位檔，我們就會淘汰該級別，且不會提早淘汰。只要沒有合作夥伴想在新的 Fuchsia 版本上執行任何以該 API 層級為目標的二進位檔，我們就會淘汰該 API 層級，但不會提早淘汰。

API 相容性保證

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

如果終端開發人員使用 任何 IDK 版本，以支援階段的 N 為目標，成功建構元件，那麼使用任何 IDK 版本，以支援階段的 N 為目標，也能成功建構相同來源碼。

換句話說，只要所選目標 API 層級尚未淘汰，終端開發人員就能放心升級或復原 IDK，不會破壞建構作業。如果更新至其他 IDK，但未變更目標 API 級別，導致建構作業中斷 (例如，使用的 API 元素已不存在)，這會視為 Fuchsia 平台錯誤。

另一方面，可變動的偽 API 級別 NEXT 和 HEAD不保證 API 相容性。指定 NEXT 或 HEAD 時，終端開發人員可能會發現更新 IDK 後，程式碼不再編譯。

就實務而言，我們目前的合作夥伴與 Fuchsia 團隊密切合作，我們會盡力避免破壞以 NEXT 為目標的終端開發人員建構作業。我們會盡量避免破壞以 HEAD 為目標的終端開發人員建構作業。

ABI 相容性保證

Fuchsia 現在會為編號 API 級別提供下列 ABI (即執行階段) 相容性保證 (須遵守下列注意事項)：

以編號 API 級別 N 為目標建構的元件，可在 Fuchsia 的任何版本上順利執行，且 N 處於支援或淘汰階段，版本間不會出現任何令人反感的行為變化。

換句話說，只要選擇的目標 API 級別尚未淘汰，終端開發人員就不必變更或重新編譯程式碼，即可在較新版本的 Fuchsia 上執行。如果平台在不同版本的 Fuchsia 上運作方式不同，導致元件功能受到干擾，這會視為 Fuchsia 平台錯誤。

另一方面，針對可變動的虛擬 API 級別 NEXT 或 HEAD，元件不保證 ABI 相容性。如果建構元件時指定 NEXT 或 HEAD，則只有在執行元件的 Fuchsia 版本與建構元件的 IDK 版本完全相符時，元件才能執行。舉例來說，以 IDK 版本 16.20231103.1.1 建構的 NEXT 目標元件會在 Fuchsia 版本 16.20231103.1.1 上執行，但不會 (預設) 在 Fuchsia 版本 16.20231103.2.1 的裝置上執行。

在大多數情況下，確保建構元件的 IDK 版本與執行元件的 OS 版本完全相符，並不可行。值得注意的例外狀況是整合測試和本機實驗。 樹狀結構外的存放區通常會控管編譯時使用的 IDK 版本，以及測試時使用的 OS 版本。如果想在 NEXT 或 HEAD 中測試功能，就必須讓兩者保持同步。

不支援的設定會遭到禁止

根據預設，如果元件的 ABI 修訂版本戳記指出該元件不在 ABI 相容性保證範圍內，component_manager 會拒絕啟動該元件。具體情形如下：

  • 如果 Fuchsia 的特定版本支援或淘汰 API 級別 N，該版本就只會執行以 N 為目標的元件。
  • 如果元件是使用完全相同的 IDK 版本建構，Fuchsia 的特定版本只會執行以 NEXT 或 HEAD 為目標的元件。

同樣地，產品組裝服務會拒絕組裝與平台不相容的產品。

產品擁有者可以選擇停用這些檢查。舉例來說，即使建構元件的 IDK 來自不同的 Fuchsia 版本，他們仍可將個別元件加入允許清單，以指定 NEXT 或 HEAD。產品擁有者必須自行承擔停用這些檢查的風險。

實作

如要實作這些檢查，必須對 ABI 修訂版本戳記進行一些變更。這些變更的完整設計超出本 RFC 的範圍，但簡而言之：

  • 與目前情況相同，每個 API 級別發布時都會獲派專屬的 ABI 修訂版本。以編號 API 級別為目標的元件，會蓋上該 API 級別對應的 ABI 修訂版本。
  • 此外，每個發布內容都會指派專屬的 ABI 修訂版本。 指定 HEAD 或 NEXT 的元件會蓋上這個每版本 ABI 修訂章。

特定版本中的 OS 二進位檔會包含支援或淘汰階段中所有 API 級別的 ABI 修訂版本清單，以及該版本的 ABI 修訂版本。根據預設，系統只允許執行蓋有其中一個 ABI 修訂版本的元件。

日後擴充功能

請注意，「每個 API 級別一個 ABI 修訂版本，外加 NEXT/HEAD 的一個版本」安排不一定是這項設計的最終版本。ABI 修訂版本是我們以機器可讀取的方式編碼 ABI 相容性保證的方式，因此如果我們的保證變得更加細緻，ABI 修訂版本的分配也必須如此。

舉例來說，假設我們將部分 API 介面指定為「長期支援 (LTS)」，並在 API 級別中持續支援 LTS API，時間比其他 API 更長。假設 F30 版本支援 API 級別 25 的 LTS API，但不支援非 LTS API。該版本只能使用 LTS API 執行以 API 級別 25 為目標的元件，但無法執行以 API 級別 25 為目標的元件 (使用非 LTS API)。因此，這兩種元件需要以不同的 ABI 修訂版本蓋章，我們可以為每個 (API 級別、LTS 狀態) 配對提供專屬的 ABI 修訂版本，達成這個目標。

我們有這方面的想法，如果選擇採用，後續的 RFC 會說明相關內容。

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

由於我們目前沒有任何機制，可讓平台元件根據連線另一端元件的 ABI 修訂版本戳記來改變行為，因此支援多個 API 級別表示同時支援多個 API 級別。平台元件的行為必須符合支援或淘汰階段中各 API 級別的規格。

更準確地說，平台元件「不得」對外部元件指定的 API 級別做出任何假設，但可假設該元件指定的是支援或已淘汰的 API 級別。

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

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

這項策略不僅限制平台元件的實作，也限制我們對平台介面進行的修改類型。從理論上來說，API 可能會從一個 API 級別任意變更為另一個 API 級別，但實際上，有些變更 (例如重複使用 FIDL 通訊協定方法序數) 會導致我們無法與以不同 API 級別為目標的外部元件正確通訊，除非有進一步的資訊。

我們可能會制定不同的策略來支援多個 API 級別，但這是日後的工作。

注意事項

API 和 ABI 相容性保證都受到一些注意事項的限制。

「保證」的意義

「保證」相容性並不代表 Fuchsia 絕不會違反相容性承諾，畢竟人難免會犯錯。也就是說，當我們根據上述條款破壞相容性時，會將其視為錯誤。我們會負責在內部解決問題，除了回報錯誤外，不需要終端開發人員採取任何行動。

保證失效

如果終端開發人員「做出奇怪的行為」，API 和 ABI 保證就不適用。包括但不限於：

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

舉例來說，根據 Fuchsia 中的錯誤行為，不會計為「執行奇怪的動作」。在某些不幸的情況下，修正錯誤可能算是「令人反感的行為變更」。如要進一步瞭解，請參閱「令人反感的變更」。

本 RFC 不會完整列出禁止行為，套用美國最高法院法官 Potter Stewart 在 Jacobellis v. Ohio 一案中的說法：「我今天不會嘗試進一步定義『做奇怪的事』，或許我永遠無法清楚地定義。但我知道自己看到的是什麼。」

令人反感的變更

ABI 相容性保證可確保元件在 Fuchsia 版本之間不會出現「令人反感的行為變更」，這些版本支援元件的目標 API 級別。「令人反感」的定義顯然是主觀的，對某些人來說是理想的變更，對其他人來說可能令人反感 (相關 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 級別

根據 Fuchsia 的事實版本控管政策，只有回溯相容的變更才能套用至開發中的 API 層級。這項 RFC 會還原該政策，因此當終端開發人員以 NEXT 為目標時，無法保證不同版本 IDK 和 OS 二進位檔之間的相容性。

如果我們在開發中的 API 級別 (或 NEXT) 內維持這項回溯相容性政策，就能做得更好：只要 OS 二進位檔來自較新的 IDK 版本，我們就能保證 IDK 和 OS 二進位檔相容。直到最近，我們都依賴這項屬性，之後才將下游存放區移至目標支援的 API 層級。

這樣一來，只要開發中的 API 級別新增 Fuchsia 功能，終端開發人員就能安全地開始使用，不必等待該 API 級別發布。

不過，這會為系統帶來顯著的複雜性：

  • Fuchsia 平台開發人員不僅必須維持與先前 API 級別的回溯相容性 (API 簽章本身會編碼在 FIDL 和標頭檔案中)，也必須維持與先前開發中 API 級別版本的回溯相容性 (這些版本不會編碼)。查看這些舊版內容的唯一方法是檢查 Git 記錄，但實際上不會發生這種情況。
  • 由於我們需要能夠從平台移除功能，因此需要某個 API 級別來支援不相容的回溯變更。也就是說，Fuchsia 平台開發人員必須在開發中的 API 級別之後，對編號 API 級別進行不相容於舊版的變更。因此，目前有兩個開發中的 API 層級，Fuchsia 平台開發人員需要同時考量這兩者。
  • 這會大幅增加 ABI 修訂的複雜度。如要支援開發中 API 級別中的回溯相容變更，我們需要無限期保留每個版本的 ABI 修訂版本 (每天會建立多個版本)。OS 二進位檔必須支援每個版本的 ABI 修訂版本，這些版本中支援的 API 級別之一是開發中的 API 級別，以及目前里程碑至今所有版本的 ABI 修訂版本。以目前的發布頻率來看，每個 API 級別最多會增加約 168 個 ABI 戳記，而截至本文撰寫時，Fuchsia 版本需要支援超過 800 個 ABI 戳記。雖然這類解決方案的記憶體成本不太可能很高，但要維持與數百、數千或數萬個不同 ABI 的相容性，似乎不值得付出這麼多心力，尤其目前沒有任何客戶使用開發中的 API 級別。

這項 RFC 並未排除日後提供額外相容性保證的可能性。

替代方案：將 API 級別與里程碑脫鉤

這項 RFC 會明確將 API 級別與里程碑編號配對。這並非必要，特別是 Android 會將這兩者分離。Android 專案會利用這項能力，在 OS 次要版本發布時一併推出 API 變更。舉例來說，API 級別 24 對應 Android 7.0，API 級別 25 則對應 Android 7.1。

在我的研究中，我找不到其他選擇採用這種做法的平台。我發現其他平台會以發布版本說明 API 元素的可用性，例如「自 Chrome 88 起可用」或「在 iOS 6.1 中已淘汰」。

macOS 和 iOS API 級別與版本管理機制相關聯，但兩者都允許在次要修訂版本中進行 API 變更，這與 Fuchsia 不同。不過，這似乎主要是因為他們希望將發布的主要版本與日曆年配對，同時仍允許每年多次發布 API 更新。

Fuchsia 的里程碑更接近 Chrome 的模式，會經常遞增主要版本，而次要版本則不會使用。如果我們希望更頻繁地穩定 API 層級，可以更頻繁地增加 Fuchsia 的里程碑編號。

替代方案：編號「開發中」API 級別

這份 RFC 的先前草稿較接近目前實作的平台版本控管模型。在該模型中，NEXT 不存在，而是以最大的編號 API 級別做為可變動的「開發中」API 級別。

在機械方面，這兩款機型只有幾項小差異：

  1. 目前，Fuchsia 平台開發人員會選擇特定 API 級別，以便推出功能。實作這項 RFC 後，他們會對 NEXT 進行與正式版相關的 API 變更，並在下一個編號 API 級別中自動發布。
  2. 目前，以開發中 API 級別為目標的終端開發人員，會在該 API 級別發布後，自動改為以支援版本為目標。實作這項 RFC 後，他們會繼續指定 NEXT。

這兩項差異似乎都不會帶來明顯的正面或負面影響。

相較於開發中的 API 層級，NEXT 的主要優點是通訊容易。這項 RFC 的先前草案曾使用口語上的花招，來表達相容性保證：「以支援的 API 級別 N 為目標建構的元件，將可在任何支援 API 級別 N 的 Fuchsia 版本上順利執行。」在目前的提案中，所有當事人都會同意特定 API 層級的內容，不需要任何限定條件。

替代做法：不要移除任何項目

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

許多平台 (包括 Windows 和 Android) 大多採用這種做法，但因此無法清除舊版 API 介面中的雜亂內容。

只要舊版 API 元素出現在支援或淘汰的 API 級別中，Fuchsia 平台工程師就必須繼續支援這些元素，但終端開發人員只需要留意所選目標 API 級別的內容，不必理會這些舊版元素。

此外，雖然「永不移除項目」可讓版本管理更簡單，但這絕非徹底解決問題的方法。根據預期安裝群組中最舊的 Fuchsia 平台版本，終端開發人員仍需判斷要指定哪個 API 級別。

  1. 目前大多數下游合作夥伴都依賴 Fuchsia 的 Canary 版本，而這類版本每天會多次發布。未來，我們會有更多合作夥伴從里程碑發布分支版本取用 IDK 和 OS 二進位檔，但目前我們很重視這種安排帶來的即時意見回饋。 ↩