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 下一个稳定版本的预发布候选版本。每个星期二（除了有发布冻结期的周），上周的每日构建版会被提升为开发者可选加入的 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 进入 weekly 或 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）中跟踪有关任何发布的最新状态。

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

发布冻结期

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

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

• 那么前一周的稳定版发布将额外保留一周，即在第 N 周不会像通常那样将新版本升级为稳定版。
• 但是，新的 beta 版和实验性版本将在冻结周（第 N 周）创建。
• 正常计划将在第 N+1 周恢复，即第 N 周的实验性/beta 版将在第 N+1 周升级为稳定版。此外，新的实验性/beta 版将在第 N+1 周创建，并在第 N+2 周升级为稳定版。
• 如果在第 N-1 周升级的稳定版最初计划在第 N 周升级为 lts 版，那么它现在将在第 N+1 周的星期一升级为 lts 版。
• nightly 版本仍会生成和升级，因为它们是完全自动化的。

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

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

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

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