セマンティックリリースによるプレリリースの公開 について動作確認してみました。元ネタはPre-releasesです。

将来のリリースを開発する中でバージョンの不要なインクリメントを回避し、ベータ版としてリリースします。

前提/制約条件

  • 最新バージョンのチャネルは@latest(branch: main or master)、プレリリースのチャンネルは@beta(branch: beta), @alpha(branch: alpha)とします
  • 次の環境で動作確認します
    • GitHub Repository(ソースコードのリポジトリ)
    • GitHub Actions(CI環境、この環境でsemantic-releaseを実行する)
    • GitHub Releases(変更履歴)
    • GitHub Packages(NPMレジストリ)

動作確認手順

元ネタの使用例の手順にそって動作確認します。

  1. 初回リリース
    feat: initial commit => v1.0.0 on @latest
    プロジェクトの初回コミットを行うところから始めます。
  2. 将来のリリース作業の開始
    feat: first feature \n\n BREAKING CHANGE: it breaks somethings => v2.0.0-beta.1 on @beta
    複数の新機能で構成される将来のメジャーバージョンの開発に取り組むことを決定しました。その一部には破壊的な変更が含まれます。テスト目的で開発された新機能毎にリリースしたいのですが、すべての機能の開発が完了するまで、リリース毎にバージョンをインクリメントしたり、開発が完了するまでユーザーに公開できないようなことは避けたいと考えています。
    これを実現するためにv1.0.0からbetaブランチを作成し、そこで開発を行います。このブランチのコミットをプッシュするとsemantic-releaseはプレリリースバージョン 2.0.0-beta.1を@betaに公開します。

    feat: second feature => v2.0.0-beta.2 on @beta
    @betaで他の機能やバグ修正をコミットしてプッシュすることで、作業を継続することができます。プッシュするたびにsemantic-releaseは新しいプレリリースを@betaに公開します。
  3. @latestでのバグ修正のリリース
    fix: a fix => v1.0.1 on @latest
    将来のリリース作業を行っている間も、@latestに変更をコミットし、リリースすることもできます。
  4. 新な将来のリリース作業の開始
    feat: first feature of other release \n\n BREAKING CHANGE: it breaks somethings => v3.0.0-alpha.1 on @alpha
    ベータ版と並行して、別の将来のメジャーバージョンの開発に取り組むことを決定しました。
    これを実現するためにbetaブランチからalphaブランチを作成し、そこで開発を行います。このブランチのコミットをプッシュするとsemantic-releaseはプレリリースバージョン 3.0.0-alpha.1を@alphaに公開します。

    feat: second feature => v2.0.0-alpha.2 on @alpha
    @alphaで他の機能やバグ修正をコミットしてプッシュすることで、作業を継続することができます。プッシュするたびにsemantic-releaseは新しいプレリリースを@alphaに公開します。
  5. @betaを@latestとして公開する
    Merge branch beta to master => v2.0.0 on @latest
    @betaで開発した機能が完成したので、@latestとしてリリースします。@betaを@latestにマージしてプッシュすることで、v2.0.0をリリースします。
  6. アルファ版をベータ版に昇格させて公開する
    Merge branch alpha to beta => v3.0.0-beta.1 on @beta
    @betaで開発していた機能は@latestにマージされリリースしたので、アルファ版をベータ版に昇格させることにしました。@alphaを@betaにマージしてプッシュすることで、v3.0.0-beta.1をリリースします。
  7. @betaを@latestとして公開する
    Merge branch beta to master => v3.0.0 on @latest
    ベータ版に昇格した機能が完成したので、@latestとしてリリースします。@betaを@latestにマージしてプッシュすることで、v3.0.0をリリースします。
  8. 更なる将来のリリース作業の開始
    Merge branch master into beta
    feat: new feature => v3.1.0-beta.1 on @beta
    引き続き、将来の開発を継続するためには、@latestの変更を@betaにマージする必要があります。

動作確認結果

手順@latest@beta@alpha
(1)v1.0.0
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(2)v2.0.0-beta.1 〜 v2.0.0-beta.2[pre-release]
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(3)v1.0.1
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(4)v3.0.0-alpha.1 〜 v3.0.0-alpha.2[pre-release]
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(5)v2.0.0
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(6)v3.0.0-beta.1[pre-release]
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(7)v3.0.0
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(8)v3.0.0-beta.1[pre-release]
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール

まとめ

@beta, @alphaの変更は、プレリリース番号がインクリメントされ、@latestにマージする際には、1つの変更として認識され、次のバージョンが決定するのが特徴です。

  • @beta, @alphaは、変更のプッシュが行われるたびにプレリリース番号がインクリメントされ、リリースされる
  • @betaを、@latestにマージする際は、1つの変更として認識され、次のバージョンを決定する

次の記事も合わせご覧ください。

CAPTCHA