semantic-release(Publishing maintenance releases)

ソフトウェア公開

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

古いバージョンに対して修正と機能を公開します。メンテナンスリリースの修正、機能は必要に応じて他のメンテナンスリリースや最新バージョンに取り込まれ、リリースします。

前提/制約条件

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

動作確認手順

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

  1. 初回リリース
    feat: initial commit => v1.0.0 on @latest
    プロジェクトの初回コミットを行うところから始めます。
  2. 破壊的な変更のリリース
    feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required => v2.0.0 on @latest
    Node.js 6のサポートを終了とし、Node.js 8以降を必要とすることにしました。これは破壊的な変更です。
  3. @1.xの機能のリリース
    feat: a feature => v1.1.0 on @1.x
    ユーザーの1人が新機能をリクエストしていますが、企業ポリシーにより、Node.js 8以降に移行できません。そのため、最新バージョンに新機能を含めても利用できないため、Node.js 6をサポートしているバージョン(v1.0.0)からメンテナンスリリース用のブランチ(1.x)を作成し、新機能を追加してリリースします。これにより、Node.js 8以降に移行できないユーザーは、メンテナンスリリースのバージョンを利用することで新機能を利用することができます。
  4. @1.0.xのバグ修正のリリース
    fix: a fix => v1.0.1 on @1.0.x
    v1.0.0を利用する別のユーザーの1人がバグを報告しているため、v1.0.0からパッチリリース用のブランチ(1.0.x)を作成し、バグ修正をリリースします。
  5. バグ修正を@1.xにマージする
    Merge branch 1.0.x to 1.x => v1.1.1 on @1.x
    @1.0.xのバグ修正を@1.xにも取り込み、リリースします。
  6. バグ修正と追加機能を@latestにマージする
    Merge branch 1.x to master => v2.1.0 on @latest
    @latestに@1.xのバグ修正と追加機能を取り込み、リリースします。
  7. 最新バージョンのバグ修正をリリース
    fix: another fix => v2.1.1 on @latest
    @latestを利用しているユーザーの1人がバグを報告しています。@latestにバグ修正を行い、リリースします。
  8. @latestのバグ修正を@1.xにマージする
    fix: another fix => v1.1.2 on @1.x
    @latestのバグ修正は、v1.1.1のユーザーにも影響があるため、@1.xにマージする必要があります。マージする際、競合を避けるため、必要なコミットをcherry-pickして取り込みます。

動作確認結果

手順@latest@1.x@1.0.x
(1)v1.0.0
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(2)v2.0.0
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(3)v1.1.0
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(4)v1.0.1
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(5)v1.1.1
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(6)v2.1.0
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(7)v2.1.1
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール
(8)v1.1.2
TAG: 作成
RELEASES: 作成
PACKAGES: 作成
通知: メール

まとめ

メンテナンスリリースは、ブランチ名を基準に次のバージョンを決定するのが特徴です。

  • メンテナンスリリースのブランチは、@letestと同様にConventional-Commitsによるバージョン生成になるが、ブランチ名を基準に次のバージョンを決定する
  • @latestの修正をメンテナンスリリースにマージする場合は、必要なコミットをメンテナンスリリース用のブランチにcherry-pickする

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

コメント