AMP 发布计划

• 发布通道
  • 每夜版
  • 每周版
    • Beta 和实验性通道
  • 长期稳定版 (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 的确切构建（可能会进行 cherry-pick 以修复最后一刻的问题；请参阅贡献代码）。

Beta 和实验性通道

Beta 和 实验性通道是 AMP 下一个 Stable 版本的预发布候选版本。每个星期二（除了有发布冻结的星期外），上周的 每夜版都会被提升到 beta 和 experimental 的开发者选择加入通道。在 1 天的时间内，我们验证这些通道中没有引入功能或性能回归后，我们会在星期三将此版本推广到一小部分流量。然后，在下周二，此同一版本将推广到 stable 通道。

可以选择加入这些通道。 有关详细信息，请参阅 [developing.md] 中的选择加入部分。

选择加入 Beta 通道旨在

• 测试和体验即将发布的 AMP 运行时版本
• 在质量保证 (QA) 中使用，以确保您的网站与下一版本的 AMP 兼容

实验性通道旨在

• 测试和体验尚未对所有用户开放的新功能
• 在质量保证 (QA) 中使用，以确保您的网站与仍在开发中的 AMP 的即将推出的功能兼容

实验性通道 可能不太稳定，并且可能包含尚未对所有用户开放的功能。

长期稳定版 (lts)

lts 发布通道每隔一个月提供以前的 stable 构建。在每个月的第二个星期一，当前 stable 版本都会升级到 lts。不建议所有 AMP 发布者都使用此通道。提供此通道是为了让希望不那么频繁地对其网站执行 QA 周期的发布者可以通过选择将特定网页加入 lts 通道来执行此操作（请参阅lts 自述文件）。

如果该月的第二个星期一恰逢节假日，则升级将在发布冻结结束后执行。

确定您的更改是否在发布版本中

Type: Release GitHub 问题用于跟踪当前和过去版本的状态；从初始版本，到通过 experimental/beta 通道进行测试，再到最终通过 stable 和 lts 通道发布。有关发布的公告会在AMP Slack #release 通道上发布（注册 Slack）。

您可以使用以下方法之一确定给定版本中的更改

• 每个版本的Type: Release GitHub 问题将包含一个指向特定发布页面的链接，其中列出了该版本中包含的更改。
• 当 PR 进入 每周 或 lts 发布版本时，会将 PR Use: In Beta / Experimental、PR Use: In Stable 和 PR Use: In LTS 标签添加到 PR。创建发布版本和添加标签之间可能会有延迟。

发布节奏

我们对发布节奏非常谨慎。

在确定我们应该多久向每个人推送 AMP 新版本时，我们必须权衡许多因素，包括

• 使用 AMP 构建的数百万个网站/数十亿个页面的稳定性
• 推送新版本时可能发生的缓存清除
• 快速推出新功能的愿望

在考虑所有这些因素后，我们得出了 1-2 周的推送周期。到目前为止，我们发现这是一个合理的折衷方案，但我们将继续评估所有这些因素，并可能会在未来进行更改。

详细计划

我们会尽可能严格地遵守此时间表，但复杂情况可能会导致延迟。您可以在 Type: Release GitHub issues 和 AMP Slack #release 频道 中跟踪任何版本的最新状态（注册 Slack）。

• 每个工作日的晚上：会自动创建新的 nightly 版本，并将其发布到 AMP Nightly Channel。
• 太平洋时间周二上午 11 点：从最近的已知良好 nightly 频道版本创建新的 experimental 和 beta 版本，并分别提供给选择加入 AMP Experimental Channel 或 AMP Beta Channel 的用户。
• 周三：我们会检查Experimental Channel和Beta Channel用户的错误报告，如果一切正常，我们会将 beta 版本推送给 1% 的 AMP 页面。
• 周四至周一：我们会继续监控Experimental Channel和Beta Channel用户的错误率和错误报告，以及使用 experimental/beta 版本的 1% 页面。
• 下周二：beta 版本将完全升级为 stable（即所有 AMP 页面现在都将使用此版本）。

版本冻结

有时我们会跳过 AMP 的生产版本发布，这称为版本冻结。

如果宣布在第 N 周进行为期一周的版本冻结

• 前一周的 stable 版本将保留额外一周，即，在第 N 周不会像通常情况下那样将新版本升级为 stable 版本。
• 但是，在冻结周（第 N 周）期间将创建新的 beta 和 experimental 版本。
• 正常时间表将在第 N+1 周恢复，即第 N 周的 experimental/beta 版本将在第 N+1 周升级为 stable 版本。此外，在第 N+1 周会创建新的 experimental/beta 版本，并在第 N+2 周升级为 stable 版本。
• 如果计划在第 N 周将第 N-1 周升级的 stable 版本升级为 lts 版本，则现在将在第 N+1 周的周一升级为 lts 版本。
• nightly 版本仍然会生成和升级，因为它们是完全自动化的。

发生版本冻结的原因可能是

• 没有足够的人员将 AMP 版本推送到 stable 版本并对其进行监控的时候。目前，执行 AMP 版本发布的大多数人员都位于美国，因此通常是在美国主要节假日（7 月 4 日独立日、11 月第四个星期四感恩节、12 月 25 日圣诞节以及 12 月 31 日/1 月 1 日新年）的几周。
• 紧急情况，例如由 技术指导委员会 (TSC) 或执行版本发布的人员确定的安全或隐私问题。
• 由 TSC 确定的代码库稳定性特别重要的其他情况。

在所有情况下，除紧急情况外，版本冻结都会提前至少一个月宣布。

请注意，除非另行宣布，否则版本冻结并不意味着代码冻结。在版本冻结期间，仍然可以编写、审查和合并代码。