Auto: 修补程序 - 支持旧的未成年人和补丁的补丁

@hipstersmoothie
您是否有任何有关如何实施/在实践中看起来如何的详细信息？

另外，我不确定我是否理解merge into a tag含义......你能澄清一下吗？ 我的理解是你只能创建一个以分支为目标的 PR。

不，我还没有真正考虑过这个问题。

另外，我不确定我是否理解合并到标签的含义

用户界面让我相信你可以合并成一个标签，但经过进一步审查，这似乎是不可能的。 如果我们可以的话，这将使这成为可能。

想起了一点，我想这就是我的想法：

1. 标签 1.2.3 存在，当前版本是 2.0
2. PR被制作成标签1.2.3，产生1.2.3-0（0是semver的构建部分）

好的，利用 semver 的构建部分绝对是有道理的。 👍

如果无法直接对标签创建 PR，则此流程可能需要 repo 所有者从上游分支（PR 的目标分支）上的标签创建分支。 这会有点烦人，但我不确定是否有更好的选择。 此外，这些类型的版本可能并不常见，所以这可能没问题。

可以使用旧的主要支持（ versionBranches ）的类似方法，其中可以在配置中指定分支前缀。 似乎此功能可能更多地针对修补程序类型的版本，因此将配置与旧的主要支持分开可能是有意义的。 你怎么认为？

示例流程可能如下所示：

• 用户在自动配置中指定使用前缀为hotfix-分支的构建标识符构建
• 现有提交日志
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

可以使用旧的主要支持（versionBranches）的类似方法，其中可以在配置中指定分支前缀。

我喜欢这个想法，但在实践中我不认为使用它会很有趣。 由于auto发布了很多，你最终会得到大量的分支。

如果无法直接对标签创建 PR，则此流程可能需要 repo 所有者从上游分支（PR 的目标分支）上的标签创建分支。 这会有点烦人，但我不确定是否有更好的选择。 此外，这些类型的版本可能并不常见，所以这可能没问题。

我同意这种类型的发布是不正常的。 这使得自动化分支创建不太有用。 如果有的话，如果没有那么多地使用它们，你会得到很多噪音（更多的分支）。

至于你上面提出的流程，似乎运作良好。 可惜我们不能把 PR 变成标签！ 将使这种工作流程更容易。

考虑到这一点，此功能可能需要在auto添加一些内容才能完全充实：

1. 新命令auto hotfix ：运行时将根据分支中的最新标记发布具有新修补程序版本的项目
2. auto shipit新功能：检测我们是否在hotfixBranch并运行auto hotfix

至于auto hotfix应该如何工作，它可以是：

1. next或canary => 新钩子，允许插件控制修补程序的发布方式，无论它是否受支持
2. 重新使用version和publish钩子并使它们能够释放build semver

在这两个选项中，我认为我倾向于1因为以新的方式调用version和pubish钩子可以被认为是一个突破性的变化。 这样做的缺点是一些钩子不会被称为afterVersion使得一些插件无法运行。 不过，目前这对canary和next都是一个问题。 因为他们也不叫那个钩子。 所以不需要立即担心的事情。

你有兴趣尝试添加这个吗？

我喜欢这个想法，但在实践中我不认为使用它会很有趣。 由于自动发布了很多，你最终会得到大量的分支。

哎呀，这意味着它在分支前缀配置方面类似于旧的主要支持。 绝对同意自动创建分支会产生太多噪音，尤其是在频繁发布的情况下，😆

考虑到这一点，这个功能可能需要一些东西到 auto 中才能完全充实：

1. 新命令自动修补程序：运行时将根据分支中的最新标记发布具有新修补程序版本的项目
2. auto shipit 的新功能：检测我们是否在 hotfixBranch 中并运行 auto hotfix

是的。 我认为这将在很大程度上封装所需的更改。

至于自动修补程序应该如何工作，它可以是：

1. next 或 canary 的方式 => 新的钩子，允许插件控制修补程序的发布方式，无论它是否受支持
2. 重用版本并发布钩子并使它们能够发布构建 semver

在这两个选项中，我认为我倾向于 1，因为以新的方式调用 version 和 pubish hooks 可能被认为是一个突破性的变化。 这样做的缺点是一些钩子不会被调用 afterVersion 使一些插件不起作用。 不过，这对于 Canary 和 next 来说目前都是一个问题。 因为他们也不叫那个钩子。 所以不需要立即担心的事情。

高水平，我认为1也有道理。 我需要跟踪代码以更好地了解为哪个命令调用了哪些钩子，但是如果next 、 canary和hotfix都遵循类似的模式，那么任何痛点都可能在以后更容易解决。

你有兴趣尝试添加这个吗？

当然👍，我很乐意。
我可能要到下周才能看到它的实现，但我猜这没问题，因为这个问题自 3 月以来就没有更新过。

惊人的！ 没有计划的工作，所以这就是你的全部

FWIW - 我打算通过做你认为是次等的选择来尝试将它构建为一个插件 - 制作一个version-MAJOR-MINOR分支。 在我们当前的过程中，TBH 感觉并没有太多的噪音。 我们已经为每个发布行创建了分支。

现在versionBranches的主要部分是这个插件：

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

添加对SEMVER.minor支持看起来微不足道，但我承认我不知道 auto 的其他哪些部分可能需要更改。

这是旧版本发生的事情的一部分，但是shipit此检查也必须通过

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

然后到这里，基本上只是覆盖从哪里开始计算发布

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

我们必须对旧的次要/补丁而不是主要考虑的一个考虑因素是潜在的版本不匹配。 对于未成年人来说，这可能不是问题

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

所以也许不需要hotfix命令。 相反，它可以尝试唯一的版本号。 不过，可能需要对此进行一些验证。

规则：

1. 不能在任何旧的次要/补丁发布分支上发布主要（必需）
2. 不能在任何旧的补丁发布分支上发布次要版本（可能没有必要？）

@hipstersmoothie
如果您有 ci 设置来构建旧标签，而下一个标签不可用，您知道现在的默认行为是什么吗？

我的猜测是会失败，虽然我不确定这个错误会在哪里发生（也许在标签推送？）。

IE：

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

除了强制执行@hipstersmoothie指定的规则try to unique version number策略/实施的一个潜在问题/混淆。 对于@hipstersmoothie给出的例子， v1.1.2会被其他人视为v1.1.1的补丁版本，但由于开发不是线性的，因此不能保证。 潜在地，甚至可能存在从v1.1.1到v1.1.2的向后不兼容更改，因为v1.1.2没有v1.1.1的更改。 如果下一个唯一版本与v1.1.0距离更大（即：如果下一个唯一版本是v1.1.100怎样？）

利用 semver 的构建元数据部分将限制这种混淆，因为根据 semver 规范，在计算版本优先级时会忽略它。 如果递增构建元数据编号，那么也许可以使用 commit sha 代替递增编号。

一般来说，软件开发不一定是线性的，因此不确定是否有最佳实现。

如果我们想要概括，那么也许我们可以有某种配置或钩子来指定上面的策略，而不管分支（或分支可以是钩子的参数）。
这样，可以通过插件使用不同的实现。

如果您有 ci 设置来构建旧标签，而下一个标签不可用，您知道现在的默认行为是什么吗？

通常标签不会构建，因为提交在消息中包含[skip ci]

如果下一个独特版本与 v1.1.0 的距离更大，这可能会变得更加严重和更加混乱

这是一个很好的观点。 绝对使版本的构建元数据部分成为正确的策略。

如果我们想要概括，那么也许我们可以有某种配置或钩子来指定上面的策略，而不管分支（或分支可以是钩子的参数）。
这样，可以通过插件使用不同的实现。

你的帖子几乎让我相信找到一个独特的标签是一个令人困惑的计划，我们可能不应该这样做。

也许如果我们进行混合，虽然它可以工作。 修补和旧的未成年人应该很容易。 对于专业，它可以以与 oldVersionBranches 完全相同的方式工作：

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

然后我们只需要做补丁补丁的构建元数据部分。

合并了from和useVerion选项后，是否有内置的修复方法？ 我今天只需要做一个，然后选择手动痛苦地做。

对于上下文，我的项目是 7.7。 我们项目的一个主要消费者目前正在发布一个 7.5 版本，发现了一个问题并需要 7.5.1，因此他们不必在发布中期对所有内容进行重新质量检查。 不是最优的，但偶尔会发生。

据我所知，如果没有人工干预，仍然无法做到这一点。 我认为 intuit 内部有人计划最终添加这个。 我同意这是汽车中非常缺少的功能

太棒了！ 谢谢🙏

我们（我和@10hendersonm）为此开发了一个解决方案，但它相当
涉及。 然而，它只使用自动和插件！

我们仅使用 PR 修复了项目的 7.2.1、8.1.1 和 8.2.2
（非常小心）。

如果人们感兴趣，我们可以研究如何分享这个？

2021 年 1 月 14 日星期四晚上 7:27，Matt Felten [email protected]写道：

太棒了！ 谢谢🙏

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 ，或
退订
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
.

我会很感兴趣的！

大家好！ 我有兴趣贡献这个。 我的建议如下：

1. 通常， auto将尝试尊重任何version-*分支。 例如，从任何分支合并到version-1.1.4的补丁将生成版本1.1.5 。 如果该版本已经创建，那么 NPM 发布或 Git 标签将失败，但这是正常和预期的错误情况
2. 我们可以更新versionBranches以接受"major" | "minor" | "patch" ，这将根据您指定的内容生成潜在的修补程序分支。 这允许您在手动需要创建version-*分支和在不需要修复时维护太多分支之间进行权衡

想法？

但这是正常和预期的错误情况\

我仍然希望这会创建某种类型的版本。 我最近有一个案例，我想从特定提交中发布修补程序，以免引入任何其他内容。 我认为在这种情况下，我们可以使用上面对话中 semver 的构建部分。

我们可以更新 versionBranches 以接受“主要” | “次要” | “修补”

当前配置可以是true或一个字符串来作为主要分支的前缀。 我认为新配置必须看起来像

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

要回答的最后一个问题仍然是hotfix hook 或 call version+publish hooks查看当前旧版本分支实现的代码，我们执行选项 2 并调用 version+publish（我认为这错误地发布到最新标签）。

@lshadler我们很多人需要在此配对一段时间才能找到最佳方法。

@bmuenzenmeyer你能概述一下你的方法吗？

我对实现的思考越多，我认为这将需要 v11 和更多的上下文添加到版本和发布命令。

对于旧版本，我们需要完整的最新管道来运行更新日志、afterVersion 以及在最新版本期间调用的所有或它们的钩子。

我们可能应该使下一个版本具有相同的版本 afterVersion 发布 afterPublish 流最新的。 这也可以是 v11 的一部分。 它应该与最新的工作流程相匹配，以便您可以添加类似的自动化。

Canary 工作流可以保持不变，因为没有为 Canary 提交任何内容，您已经可以点击 Canary 钩子来做更多的事情。

大家好，由于去年的疯狂，不幸的是这个问题已经离我而去。

关于不同的方法，我认为考虑这些功能解决的不同用例可能会有所帮助。 在我看来，我可以看到 2 个用例：

• (1) 对旧分支的长期支持（即：旧的主要版本）
• (2) 对特定版本的短期支持（即：hotfix）

基于这次谈话，我认为为每个用例采用不同的方法是有意义的。

(1) 对于分支/发布轨道的长期支持，我相信versionBranches应该能够解决。 如果希望为次要版本扩展此行为（正如上面提到的一些），那么这可能是对该功能的增强。

(2) 对于短期支持/修补程序，基于上述线程，我认为应该有标准的方式让用户始终使用 semver 的构建部分来生成修补程序版本。 这为代码所有者提供了一致的使用行为，并避免了一些复杂的极端情况。 对于这种情况，我认为可以使用新的修补程序命令和钩子。 这可能是一个明显的增强。 一般来说，这种用例应该相对较少，因为应该鼓励消费者尽可能使用最新的版本。

编辑_（对于短期用例，可能会扩展versionBranches配置以允许参数/切换/标志表示是否遵守version-分支的 semver 标签或始终使用semver 的构建部分并忽略这些分支的任何标签）_

除了这 2 个用例之外，还有其他用例需要考虑吗？

是否应该针对不同的用例考虑不同的方法？

（此外，我仍然可以帮助完成其中一些更改，但绝对不想阻止其他人为此进行更改）

此外，对分支模式的切向思考：

auto 将为发布生成一个 git 标签（发布）。 这意味着一个有效的 git ref 被推送到 github。 对于短期支持的用例（即：短期分支/修补程序分支），这意味着用户可以在推送发布/git 标签后删除短期分支。

• 给定一个带有以下标签的主分支
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

对于短期分支，在添加功能时记录上述分支模式可能会很好。 我个人发现很多人不知道您可以删除分支并仍然引用新的提交，这可能有助于不同的项目减少短期分支的混乱。

我最近在玩代码以利用 semver 的构建部分来创建构建。 当我这样做时，我遇到了一个用例，其中最新的 github 版本不一定是最新/最高的语义版本。

例如，在此处提到的示例中： https : v1.2.3+1因为它是在最高版本之后临时创建的版本语义版本： v1.3.0 。

由于代码中有相当多的地方引用了getLatestRelease ，如果管道没有明确设置from参数，这可能会导致不同的行为。 IE：

• 发行说明中包含的内容
• 以前的版本计算为
• 如果从 HEAD 提交无法访问最新的 github 版本，则可能会破坏功能

我还没有测试过，但我相信这些类型的场景也可以通过现有的versionBranches行为来访问。 我相信这与关于哪些流应该生成 git 标签/ github 版本的评论有关：

要回答的最后一个问题仍然是hotfix hook 或 call version+publish hooks查看当前旧版本分支实现的代码，我们执行选项 2 并调用 version+publish（我认为这错误地发布到最新标签）。

在解决方面，通过将getLatestRelease逻辑替换为：

• (1) 使用listReleases获取 github 发布，然后排序以找到可访问的最高发布版本（没有预发布或构建部分）
• (2) 或获取 git 标签，然后排序以找到可访问的最高发布版本（无预发布或构建部分）

这里的区别在于auto是否将 github 版本或 git 标签视为事实来源，这与讨论有关https://github.com/intuit/auto/discussions/1867#discussioncomment -684192。

我最初倾向于（2），因为

• (a) 我们最终是在 git ref (tag) 而不是 github 版本的其他元素之后
• (b) 它会减少网络调用的数量

@hipstersmoothie ,
如果我们需要修改getLatestRelease逻辑，您对 (1) 使用 github 版本 vs (2) 使用 git 标签 vs (3) 其他东西有何看法？

是的，要使多包自动工作，它需要将所有最新的 GitHub 发布内容重构为仅标记。 2是完成这项工作的首选选项。