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 的确切版本（可能会进行挑选以修复最后一分钟的问题；请参阅贡献代码）。

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 问题和 AMP Slack #release 渠道（注册 Slack）中跟踪有关任何发布的最新状态。

• 每个工作日晚上：会自动截取并发布新的 每夜构建版，以供AMP 每夜构建版渠道使用。
• 星期二 @ 太平洋时间上午 11 点：从最近的已知良好每夜构建版渠道版本创建新的 experimental 和 beta 版本，并分别提供给加入 AMP 实验性渠道或 AMP Beta 渠道的用户。
• 星期三：我们会检查 实验性渠道和 Beta 渠道用户的错误报告，如果一切正常，我们会将 beta 推送到 1% 的 AMP 页面
• 星期四至星期一：我们会继续监控 实验性渠道和 Beta 渠道用户的错误率和错误报告，以及使用 experimental/beta 构建的 1% 的页面
• 下周二：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 版本。
• nightly 版本仍然会生成和晋升，因为它们是完全自动化的。

发生发布冻结的原因可能是

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

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

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