跳到主要内容

补丁版本

什么是补丁版本？​

补丁版本是针对特定问题而发布的，不包含大量新功能的修复版本。补丁版本通常包含：

  • 关键的错误修复，影响商店功能或结账流程。
  • 安全补丁，用于解决紧急漏洞。
  • 兼容性修复，用于解决 WordPress、主题或插件冲突。

确定补丁版本的发布时间​

在确定发布补丁版本的最佳时间时，请根据未解决问题的紧迫性和严重程度，运用您的最佳判断：

  • 如果问题不太紧急，请考虑等待 3-4 天，看看是否会报告其他相关问题，然后再继续。这有助于整合修复，并减少补丁版本的数量。
  • 对于高危或关键问题，应优先尽快发布，以最大限度地减少对用户的潜在影响。
  • 对于安全问题，请与实施安全修复的团队协调，以帮助确定紧迫性，如果情况尚不清楚。
  • 考虑是否已经有其他已知问题正在处理，这些问题可以包含在同一版本中。

补丁版本请求 (PRR) 流程​

补丁版本请求 (PRR) 流程 是一个结构化的过程，用于请求和管理需要包含在 WooCommerce 补丁版本中的关键修复。 此过程可确保紧急错误修复可以安全地合并到当前的稳定版本中，并自动将其移植到主分支和任何冻结分支，从而保持代码质量，强制进行彻底的审查，并防止出现回归。

⚠️ 重要： 安全漏洞报告不应通过 PRR 流程。 所有潜在的安全问题应通过 Automattic 的 HackerOne 计划私下报告：https://hackerone.com/automattic/。

步骤流程​

1a. 初始问题创建​

为了确保发布负责人了解所有计划包含在下一个补丁版本中的修复，当发现一个错误并计划将其作为修复时，重要的是立即创建问题或 PR。 这将有助于减少需要创建的补丁版本的数量。

如果初始 PR 的创建可能需要几个小时以上，请创建一个问题，并将问题的里程碑设置为目标版本。 例如，对于 10.1.x 的新补丁版本请求，请使用里程碑 10.1.0。

1b. 初始拉取请求创建​

作者操作: 创建一个拉取请求，针对发布分支 (release/x.y)，而不是主分支，并遵循标准的 PR 创建流程。

  • PR 应该针对特定的发布分支（例如，对于 WooCommerce 9.5.x 中发现的问题，请使用 release/9.5）。
  • 包含一个常规的变更日志文件，就像为主分支的 PR 所做的那样。
  • 确保满足所有标准 PR 要求（描述、测试等）。
  • 确保 PR 设置了目标版本的里程碑，以便发布负责人可以跟踪它，例如，对于 10.1.x 的新补丁版本请求，请使用里程碑 10.1.0。

2. 细分版本请求提交​

作者操作: 使用 细分版本请求模板 提交细分版本请求 (PRR)。

提供所需的细分版本请求模板信息：

必填字段：

  • PR URL: 针对发布分支的拉取请求 URL
  • Justification: 为什么需要此细分版本
  • Impact Assessment: 如果不包含此修复，可能造成的后果（受影响的用户数量以及影响方式）
  • Contingency Plan: 如果在细分版本发布后发现缺陷，应该怎么办
  • Communication Plan: 如何在发布博客文章中宣传此更改
  • Workaround: 任何可用的临时解决方案以及如何告知用户
  • Alternative Contact: 如果作者不可用，应该联系谁

3. 发布负责人审核​

当提交了细分版本请求后，发布负责人会进行评估。 在决定是否批准细分版本请求时，发布负责人应考虑以下因素：

评估标准指导
影响范围已经有多少商店受到影响？ 影响范围越大，紧急程度越高。
错误常见性该问题是否源于广泛使用的核心功能、插件或主题？ 常见组件中的问题通常需要更快的处理。
Workarounds是否存在简单的、经过文档记录的临时解决方案（例如，过滤器、设置切换或临时功能禁用），商店所有者可以应用？ 容易获得的临时解决方案会降低对细分版本的需求。
影响严重性该错误是否会阻止关键的商业功能（结账、支付、产品可见性）？ 商业功能失败越关键，优先级越高。

4. 批准或拒绝​

结果发布负责人操作触发的工作流
批准为细分版本请求问题添加 Approved 标签，并可以选择留下简短的理由，引用上述标准。工作流会自动为 PR 添加标签（“cherry pick to trunk”，“cherry pick to frozen release”）；将问题的里程碑设置为当前发布版本；在细分版本请求中添加批准说明。
拒绝添加 Rejected 标签，并简要说明原因（例如，影响范围有限，有简单的临时解决方案可用）。工作流会添加一条评论，关闭细分版本请求，作者必须将 PR 重新定向到 trunk 分支，解决冲突，并通过正常的流程合并。

5. 合并到发布分支 (发布负责人 / 核心贡献者)​

  • 验证 cherry-pick 要求

    • 检查该修复是否已包含在 trunk 和/或下一个冻结分支中。
    • 如果该修复不应该被移植到未来版本，移除 cherry pick to trunk 和 cherry pick to frozen release 标签。

  • 合并 PR

    • 在审查标签后，将 PR 合并到当前的 release/x.y 分支。
    • 确认变更日志条目和里程碑是否正确。

  • 结果自动化

    • 如果任一 cherry-pick 标签仍然存在，GitHub Actions 会打开后续 PR，目标是 trunk 和/或冻结的发布分支。
    • 如果两个标签都被移除，则不会运行任何 cherry-pick 工作流。

6. 审查和合并后续 PR (发布负责人)​

在主修复合并到 release/x.y 后，PR 上剩余的标签将决定下一步的操作：

标签存在自动化结果发布负责人必须做什么
cherry pick to trunkAction 打开一个新的 PR，目标是 trunk，并添加当前的里程碑。审查测试 / CI，并合并此 PR。
cherry pick to frozen releaseAction 打开一个新的 PR，目标是 下一个冻结分支（例如，release/9.6），并添加里程碑。审查并合并此 PR。

这两个后续 PR 必须在创建 point-release 标签之前合并。 如果不需要任何 cherry-pick，请确保在步骤 5 中移除了相应的标签，以避免生成不必要的 PR。

7. 发布 point release (发布负责人)​

一旦所有必需的 PR 都已合并到：

  • release/x.y (当前维护分支)
  • trunk (未来的特性分支)
  • 可选 冻结分支 (release/x.y+1)

发布负责人 创建并发布新的 point release，其中包含自上次发布以来所有已批准的 PRR。

请遵循已建立的 WooCommerce 发布流程。