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 发布渠道，上周的最后一个 nightly 发布版本会升级到 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 版本的预发布候选版本。每个周二（除非有发布冻结的周），上周的 nightly 会被提升到开发人员可选的 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 问题和 AMP Slack #release 渠道（注册 Slack）中跟踪有关任何发布的最新状态。

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

发布冻结

有时我们会跳过将 AMP 发布到生产环境，这称为发布冻结。

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

• 上周的稳定版将额外保留一周，即不会像通常情况下那样在第 N 周将新版本升级到稳定版。
• 但是，新的 beta 和实验性版本将在冻结周（第 N 周）期间创建。
• 正常计划将在第 N+1 周恢复，即第 N 周的实验性/beta 版本在第 N+1 周升级到稳定版。此外，新的实验性/beta 版本将在第 N+1 周创建，并在第 N+2 周升级到稳定版。
• 如果第 N-1 周升级的稳定版原计划在第 N 周升级到 lts，则现在将在第 N+1 周的周一升级到 lts。
• 每夜构建版本仍会生成和升级，因为它们是完全自动化的。

发布冻结可能发生在以下情况下

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

在所有情况下（紧急情况除外），发布冻结将提前至少一个月宣布。

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