Auto: 自定义凹凸提交消息

我可能更喜欢没有碰撞提交（就像semantic-release那样）：

{
  "skipBumpCommit": true
}

禁用凹凸提交后，最新的 NPM 版本是事实的来源（或者它可能已经这样工作了？）并且package.json的“版本”字段可以设置为0.0.0-development或类似的。

travis 上的跳过 CI 有什么不同？ 如果没有在您的提交消息中，您很容易陷入循环

auto将使用查看本地版本和发布版本并选择较高的一个以避免 npm 错误。 够了吗？

travis 上的跳过 CI 有什么不同？ 如果没有在您的提交消息中，您很容易陷入循环

我不确定。 如果在提交标头中需要它，那就这样吧。 😆

auto将使用查看本地版本和发布版本并选择较高的一个以避免 npm 错误。 够了吗？

哦真的吗？ 好的。 在这种情况下没有创建凹凸提交吗？

不，在这种情况下，我们会修改已发布的版本，因为您可以发布旧版本。

我无法想象skipBumpCommit将如何工作或最终结果会是什么样子。 要运行shipit您必须以某种方式更改版本，所以我看不出您如何摆脱该提交。

当package.json的版本类似于0.0.0-development时，您如何看待shipit跳过碰撞提交？

1. 包从 0.0.0-development 开始

2. 你运行version它返回基于 PR 的凹凸，它返回任何东西（补丁，次要，主要） - 可以说它是补丁

3. 更改日志创建 - (0.0.0-development => 0.0.0)。 但你不希望这种情况发生吗？ 而是在“0.0.0-development”变更日志标题下添加？

4. 发布挂钩时间 - 它将 0.0.0-development => 0.0.0 并发布。 但您希望development被检测到并一起跳过发布步骤

5. 发布 github 版本 - 不是创建新版本，而是使用新提交更新旧版本

6. 包保持在 0.0.0-development 直到 ??? 当变化累积时

如果那是您想要的，则有两种选择：

1. 在您想要开始发布和发布之前，不要运行auto shipit 。 仍然将标签添加到您的 PR 中。 当您准备好时，将auto shipit到您的 CI 流程中，它将在您的第一个版本中包含所有标签 PR。

2. 写一个插件。 这种行为非常独特，并不真正符合 npm 进行版本控制的方式。 我认为您可以制作一个插件来完成这些工作。 尽管我可能需要添加一两个钩子供您使用。

版本为0.0.0-development表示以下内容：

• 发布的最高 NPM 版本被认为是“当前版本”
• version中的package.json永远不应该改变

当应该发布新的 NPM 版本时，Auto 应该使用npm version $(auto version)增加“当前版本”。

更改日志使用 NPM 中的“当前版本”（而不是package.json ）。

与往常一样，每个 NPM 版本都会创建一个新的 Github 版本。

我说得够清楚了吗？

永远不应更改 package.json 中的版本

要将新版本发布到 NPM，您必须更改此设置。 增加“当前版本”并且永远不会更改本地版本的唯一方法是：

• 将其更改为当前版本 (NPM)
• 做碰撞
• 改回来
• 但因为它的标签将是凹凸当前版本吗？？？

我很确定我理解你的用例。

一种。 当您在多个 PRS 上开发功能时，您不想发布一堆版本
湾一旦应该发布新版本，您希望包含所有更改

在我看来，我们已经为您提供了两种方法来做到这一点：

1. 使用onlyPublishWithReleaseLabel 。 在您添加此标签之前，不会创建新版本。 因此，您可以将任何没有标签的 PR/代码视为VERSION-development

2. 当您为大功能合并 PR 时，请使用skip-release直到您准备好一个版本，然后只需合并一个 PR。 新版本包含所有跳过的 PR。 在这种情况下，您可以将skip-release标签添加为表示您的版本是VERSION-development

这与您想要的行为有何不同？

在我看来，可以归结为：您想将-development到您的版本中以开始跳过版本并在您准备好立即发布所有更改时将其删除。

为了完成我的最后一句话，您可能会制作一个插件，该插件使用beforeShipit来检查版本中是否存在-development ，如果存在则抛出错误。 这将阻止shipit向前移动，直到您删除-development 。

我看到的唯一问题是它也会使 CI 工作失败。

有趣的解释，但不是我想要的。 😅

我基本上是在描述semantic-release是如何工作的。

我_应该_说“ package.json中的版本只是为了让npm publish成功而暂时更改”（而不是“ package.json的版本永远不应更改”）。 我真正想做的就是完全避免碰撞提交。 :)

好的，所以你最终会处于的状态是：

回购：只有版本 0.0.0-dev

npm：始终拥有真实版本（这是用于任何事情的内容）

正确的？

有点像

        if (auto.options.skipBumpCommit) {
          // get published version
          // change local version to publish
        } else {
          await execPromise('npm', [
            'version',
            latestBump || version,
            '-m',
            '"Bump version to: %s [skip ci]"'
          ]);
        }

        await setTokenOnCI();

        await execPromise(
          'npm',
          !isPrivate && isScopedPackage
            ? ['publish', '--access', 'public']
            : ['publish']
        );

        if (auto.options.skipBumpCommit) {
          // change local version back to DEV
        } 

        await execPromise('git', [
          'push',
          '--follow-tags',
          '--set-upstream',
          'origin',
          '$branch'
        ]);
      }

是的，看起来不错！

auto v4.0.0 我们来啦哈哈。 看起来我将不得不拆分publish挂钩。 这将是另一个插件

如果你愿意，你现在可以把这个特性烘焙到 Auto 中，然后等待拆分publish钩子，直到另一个插件也需要它。 😛

现在应该可以通过插件使用 #247（semver 功能）来实现。 提交消息需要一些配置更改，并没有真正让您受益。 关闭但对 PR 开放！