Auto: カスタムバンプコミットメッセージ

私はバンプコミットを好まないかもしれません（ semantic-releaseがそれをするように）：

{
  "skipBumpCommit": true
}

バンプコミットを無効にすると、最新のNPMバージョンが信頼できる情報源になり（または、すでにそのように機能している可能性がありますか？）、 package.jsonの「バージョン」フィールドを0.0.0-developmentなどに設定できます。

スキップCIはtravisで異なりますか？ コミットメッセージにそれがないと、簡単にループに陥る可能性があります

autoは、ローカルバージョンと公開バージョンを確認し、npmエラーを回避するために高い方を選択します。 それで十分ですか？

スキップCIはtravisで異なりますか？ コミットメッセージにそれがないと、簡単にループに陥る可能性があります

実際にはわかりません。 コミットヘッダーで必要な場合は、そうしてください。 😆

autoは、ローカルバージョンと公開バージョンを確認し、npmエラーを回避するために高い方を選択します。 それで十分ですか？

まあ、本当に？ 良い。 その場合、バンプコミットは作成されませんか？

いいえ、その場合、古いバージョンの上に公開できるため、公開されたバージョンをバンプします。

skipBumpCommitがどのように機能するか、または最終結果がどのようになるかを視覚化するのに問題があります。 shipit実行するには、何らかの方法でバージョンを変更する必要があるため、そのコミットから抜け出す方法がわかりません。

package.jsonのバージョンが0.0.0-developmentようなものである場合、 shipitがバンプコミットをスキップすることについてどう思いますか？

1. パッケージは0.0.0から始まります-開発

2. versionを実行すると、PRに基づいてバンプが返され、すべて（パッチ、マイナー、メジャー）が返されます-パッチだとしましょう

3. 変更ログの作成-（0.0.0-開発=> 0.0.0）。 しかし、あなたはそれが起こらないようにしたいですか？ 代わりに、「0.0.0-development」変更ログタイトルの下に追加しますか？

4. 公開フック時間-それは0.0.0になります-開発=> 0.0.0そして公開します。 ただし、 developmentを検出して、公開手順をすべてスキップする必要があります

5. githubリリースを作成する-新しいリリースを作成する代わりに、古いリリースを新しいコミットで更新します

6. パッケージは0.0.0のままです-???まで開発中変化が蓄積する間

それが必要な場合は、2つのオプションがあります。

1. リリースと公開を開始するまで、 auto shipit実行しないでください。 それでもPRにラベルを追加します。 準備ができたら、CIプロセスにauto shipitを追加すると、最初のリリースにすべてのラベルPRが含まれます。

2. プラグインを作成します。 この動作は非常にユニークであり、npmがバージョン管理を行う方法に実際には準拠していません。 私はあなたがこのことを達成するためのプラグインを作ることができると思います。 私はおそらくあなたが利用するためにフックを1つか2つ追加する必要があるでしょうが。

バージョンが0.0.0-developmentのパッケージは、次のことを示します。

• 公開されている最高のNPMバージョンは「現在のバージョン」と見なされます
• versionでpackage.json変更すべきではありません

新しいNPMバージョンを公開する必要がある場合、Autoはnpm version $(auto version)を使用して「現在のバージョン」をインクリメントする必要があります。

変更ログは、（ package.jsonからで

いつものように、新しいGithubリリースはすべてのNPMバージョンに対して作成されます。

私は十分に明確ですか？

package.jsonのバージョンは決して変更しないでください

新しいバージョンをNPMに公開するには、これを変更する必要があります。 「現在のバージョン」をインクリメントし、ローカルバージョンを変更しない唯一の方法は次のとおりです。

• 現在のバージョン（NPM）に変更します
• バンプを行う
• 元に戻す
• しかし、それはタグがバンプの現在のバージョンになるので、そうしますか？

私はあなたのユースケースを理解していると確信しています。

NS。 複数のPRSで機能を開発しているときに、多数のバージョンを公開したくない
NS。 新しいバージョンが公開されたら、すべての変更を含める必要があります

私の目には、これを行うための2つの方法がすでにあります。

1. onlyPublishWithReleaseLabelます。 このラベルを追加するまで、新しいバージョンは作成されません。 したがって、ラベルのないPR /コードをVERSION-developmentとして見ることができます。

2. 大きな機能のPRをマージするときは、バージョンの準備ができるまでskip-release使用してから、PRをマージするだけです。 新しいリリースには、スキップされたすべてのPRが含まれています。 この場合、バージョンがVERSION-developmentであることを示すためにskip-releaseラベルを追加することを確認できます。

これはあなたが望む振る舞いとどう違うのですか？

要約すると、バージョンに-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に開放されています！