AMP 發佈排程

• 發佈管道
  • 每夜版
  • 每週版
    • Beta 和 Experimental 管道
  • 長期穩定版 (lts)
• 判斷您的變更是否包含在發佈版本中
• 發佈頻率
  • 詳細排程
  • 發佈凍結期

AMP 的新版本每週二都會推送至所有 AMP 頁面。AMP 的變更一旦合併到 amphtml 儲存庫的主要分支，通常需要 1-2 週才能對所有使用者生效。

AMPHTML 驗證工具有其自己的發佈排程

發佈管道

AMP 執行階段和擴充功能是透過各種不同的發佈管道提供。每個管道都為開發人員和 AMP HTML 專案本身服務。請參閱發佈頻率章節，以更詳細地瞭解來自ampproject/amphtml儲存庫的程式碼如何以及何時進入發佈版本。

若要判斷 PR 是否已包含在下列任何發佈管道中，請尋找 GitHub 標籤 PR Use: In Canary、PR Use: In Production 或 PR Use: In LTS (詳情請參閱判斷您的變更是否包含在發佈版本中章節)。

每夜版

每夜版發佈管道 (顧名思義) 每週工作日都會更新。此程序是自動化的，且不保證任何給定的每夜版發佈版本都沒有錯誤或其他問題。每天午夜 (太平洋時間) 過後，會選取當天最後一個「綠色」提交作為發佈截止點。綠色建置表示所有自動化測試都已通過該建置。

每夜版發佈提供一種機制，可快速偵測並解決問題，然後再讓這些問題影響流量更大的每週發佈管道。它也有助於減少受新引入問題影響的使用者數量。

可以選擇加入每夜版管道，以測試過去幾天合併的提取請求。詳情請參閱 [developing.md] 中的選擇加入章節。

每週版

每週發佈管道被視為主要的「永久有效」發佈管道。每週，前一週的 beta 發佈版本會升級為 stable 發佈管道，而前一週的最後一個 每夜版 發佈版本會升級為 experimental 和 beta 發佈管道 (請參閱詳細排程)。

建立發佈版本時，會使用兩組建置組態：canary 組態和 production 組態。experimental 和 beta 發佈管道是根據相同的提交建置的。但是，experimental 管道使用 canary 組態，而 beta 管道使用 production 組態。canary 組態啟用可能在 production 中關閉的實驗性元件和功能。可以透過 實驗頁面選擇加入 experimental 或 beta 管道。

stable 發佈管道是使用 production 組態建置，並提供給大多數 AMP 流量。由於 beta 發佈管道也是從 production 組態建置的，因此它代表下週將成為 stable 的確切建置版本 (可能會進行挑選以修正最後一刻的問題；請參閱貢獻程式碼)。

Beta 和 Experimental 管道

Beta 和 Experimental 管道是 AMP 下一個 Stable 發佈版本的預先發佈候選版本。每週二 (除非遇到發佈凍結期)，上週的 每夜版 會升級為開發人員選擇加入的 beta 和 experimental 管道。在 1 天期間，我們會驗證這些管道中沒有引入任何功能或效能衰退，然後在週三將此版本推廣到一小部分流量。此相同版本接著會在下週二推廣到 stable 管道。

可以選擇加入這些管道。詳情請參閱 [developing.md] 中的選擇加入章節。

選擇加入 Beta 管道的目的是為了

• 測試和試用即將發佈的 AMP 執行階段版本
• 在品質保證 (QA) 中使用，以確保您的網站與下一個 AMP 版本相容

Experimental 管道的目的是為了

• 測試和試用尚未向所有使用者開放的新功能
• 在品質保證 (QA) 中使用，以確保您的網站與仍在開發中的 AMP 即將推出的功能相容

Experimental 管道可能較不穩定，且可能包含尚未向所有使用者開放的功能。

長期穩定版 (lts)

lts 發佈管道提供先前 stable 建置版本，間隔為一個月。在每個月的第二個星期一，目前的 stable 發佈版本會升級為 lts。不建議所有 AMP 發佈商使用此管道。它提供給希望較不頻繁地在其網站上執行 QA 週期的發佈商，方法是將特定網頁選擇加入 lts 管道 (請參閱 lts 讀我檔案)。

如果每個月的第二個星期一遇到假日，則升級將在發佈凍結期結束後執行。

判斷您的變更是否包含在發佈版本中

Type: Release GitHub 問題用於追蹤目前和過去發佈版本的狀態；從初始剪輯、透過 experimental/beta 管道進行測試，到最終透過 stable 和 lts 管道發佈。關於發佈版本的公告會在 AMP Slack #release 頻道 (註冊 Slack) 上發佈。

您可以使用下列其中一種方法，判斷給定發佈版本中包含哪些變更

• 每個發佈版本的 Type: Release GitHub 問題都會包含指向特定發佈頁面的連結，其中列出該發佈版本中包含的變更。
• PR Use: In Beta / Experimental、PR Use: In Stable 和 PR Use: In LTS 標籤會在 PR 進入每週或 lts 發佈版本時新增至 PR。發佈版本建立與標籤新增之間可能會有延遲。

發佈頻率

我們在發佈頻率方面刻意謹慎。

在決定我們應該多久向所有人推送新版本的 AMP 時，我們必須權衡許多因素，包括

• 使用 AMP 建置的數百萬個網站/數十億個網頁的穩定性
• 當我們推送新版本時可能發生的快取失效
• 快速推出新功能的渴望

在考量所有這些因素後，我們已確定 1-2 週的推送週期。到目前為止，我們發現這是一個合理的折衷方案，但我們將繼續評估所有這些因素，並可能在未來做出變更。

詳細排程

我們盡力嚴格遵守此排程，但複雜情況可能會導致延遲。您可以在Type: Release GitHub 問題和 AMP Slack #release 頻道 (註冊 Slack) 中追蹤任何發佈版本的最新狀態。

• 每週工作日晚上：會自動剪輯新的 每夜版 建置版本，並發佈到 AMP 每夜版管道。
• 週二太平洋時間上午 11 點：從最近已知的良好每夜版管道發佈版本建立新的 experimental 和 beta 發佈版本，並分別提供給選擇加入 AMP Experimental 管道或 AMP Beta 管道的使用者。
• 週三：我們會檢查 Experimental 管道和 Beta 管道使用者的錯誤報告，如果一切順利，我們會將 beta 推送到 1% 的 AMP 頁面
• 週四至週一：我們會繼續監控 Experimental 管道和 Beta 管道使用者以及 1% 具有 experimental/beta 建置版本的頁面的錯誤率和錯誤報告
• 下週二：beta 發佈版本會完全升級為 stable (即所有 AMP 頁面現在都將使用此發佈版本)

發佈凍結期

有時我們會跳過 AMP 的生產發佈版本，這稱為發佈凍結期。

如果宣佈第 N 週為期一週的發佈凍結期

• 前一週的 stable 發佈版本將額外保留一週，即在第 N 週不會將新版本升級為 stable，如同正常情況一樣。
• 不過，新的 beta 和 experimental 發佈版本將在凍結期 (第 N 週) 期間建立。
• 正常排程將在第 N+1 週恢復，即第 N 週的 experimental/beta 發佈版本會在第 N+1 週升級為 stable。此外，新的 experimental/beta 發佈版本會在第 N+1 週建立，並將在第 N+2 週升級為 stable。
• 如果在第 N-1 週升級的 stable 發佈版本原定於第 N 週升級為 lts，則現在將在第 N+1 週的星期一升級為 lts。
• 每夜版發佈版本仍會產生和升級，因為它們是完全自動化的。

發佈凍結期可能會因下列原因而發生

• 在沒有足夠人員可以將 AMP 發佈版本推送至 stable 並監控它的時間。目前，大多數執行 AMP 發佈的人員都位於美國，因此這通常會是美國主要節日的週，例如獨立紀念日 (7 月 4 日)、感恩節 (11 月的第四個星期四)、聖誕節 (12 月 25 日) 和新年除夕/元旦 (12 月 31 日/1 月 1 日)。
• 緊急情況，例如由技術指導委員會 (TSC) 或執行發佈的人員判斷的安全或隱私問題。
• TSC 判斷程式碼庫的穩定性被認為特別重要的其他情況。

在所有情況下，除了緊急情況外，發佈凍結期都會至少提前一個月宣佈。

請注意，除非另行宣佈，否則發佈凍結期並不表示程式碼凍結。程式碼仍可能在發佈凍結期期間撰寫、審查和合併。