セマンティックリリースによるメンテナンスリリースの公開 について動作確認してみました。元ネタは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レジストリ)
動作確認手順
元ネタの使用例の手順にそって動作確認します。
- 初回リリース
feat: initial commit => v1.0.0 on @latest
プロジェクトの初回コミットを行うところから始めます。 - 破壊的な変更のリリース
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以降を必要とすることにしました。これは破壊的な変更です。 - @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以降に移行できないユーザーは、メンテナンスリリースのバージョンを利用することで新機能を利用することができます。 - @1.0.xのバグ修正のリリース
fix: a fix => v1.0.1 on @1.0.x
v1.0.0を利用する別のユーザーの1人がバグを報告しているため、v1.0.0からパッチリリース用のブランチ(1.0.x)を作成し、バグ修正をリリースします。 - バグ修正を@1.xにマージする
Merge branch 1.0.x to 1.x => v1.1.1 on @1.x
@1.0.xのバグ修正を@1.xにも取り込み、リリースします。 - バグ修正と追加機能を@latestにマージする
Merge branch 1.x to master => v2.1.0 on @latest
@latestに@1.xのバグ修正と追加機能を取り込み、リリースします。 - 最新バージョンのバグ修正をリリース
fix: another fix => v2.1.1 on @latest
@latestを利用しているユーザーの1人がバグを報告しています。@latestにバグ修正を行い、リリースします。 - @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する
次の記事も合わせご覧ください。
コメント