standard-version vs semantic-release: バージョニング
standard-versionは、あなたが選んだときにローカルでバージョンとchangelogを上げます。semantic-releaseは、CIでコミット履歴からバージョニングと公開を完全に自動化します。
standard-versionはConventional Commitsを読んでバージョンを上げ、changelogを更新し、タグを付けますが、実行してリリースをpushするのはあなたで、人間が関与し続けます。semantic-releaseはパイプライン全体を引き受けます。CIでコミットから次のバージョンを決定し、ノートを生成し、npmに公開し、手動ステップなしにGitHub releaseを作成します。standard-versionは制御を、semantic-releaseは完全な自動化を提供します。(standard-versionは現在フォークに取って代わられ非推奨ですが、このモデルは広く使われています。)
| standard-version | semantic-release | |
|---|---|---|
| トリガー | 手動(自分で実行) | CIで自動 |
| 公開 | 自分でpush/公開 | 完全自動 |
| 制御 | 高い(人間のゲート) | 低い(ノータッチ) |
| セットアップ | シンプル | より多くのプラグイン/設定 |
| 最適な用途 | 制御されたリリース | 継続的デリバリー |
CIでの利用
semantic-releaseはCI向けに作られています。リリースブランチにマージすると、バージョン付け、タグ付け、公開、ノート作成を自動で行い、継続的デリバリーに理想的です。standard-versionは、コミット駆動の更新は欲しいが、いつリリースを切り出してpushするかは人間が決めたいチームに向いています。どちらも規律あるConventional Commitsに依存します。
高速化する
依存関係をキャッシュしてリリースジョブが素早く始まるようにします。どちらもCIランナー上で実行されるビルドから公開し、より高速なマネージドランナーはbuildと公開のステップを短縮します。
結論
条件を満たすマージごとに完全自動でノータッチの公開が欲しい場合: semantic-release。コミット駆動のバージョンとchangelogの更新は欲しいが、いつリリースするかは人間が決めたい場合: standard-version(またはメンテナンスされているフォーク)。リリースの切り出しにどれだけ手動制御が欲しいかで選びましょう。