feat: automate version management with release-plz

[ppputtyo]

概要

バージョン管理を手動（#214 のような bump up PR）から release-plz による自動化に移行する。

背景

• バージョン番号を各 Cargo.toml / package.json に手動で書き換えていた
• CHANGELOG がない
• Git タグがない
• main への push ごとに GitHub Pages へデプロイされ、リリースの概念が曖昧だった

変更内容

1. Cargo.toml: workspace version の一元化

全クレートのバージョンを [workspace.package] で一元管理するように変更。

# ルート Cargo.toml
[workspace.package]
version = "1.0.1"

# 各クレートの Cargo.toml
version.workspace = true

2. release-plz の導入

• release-plz.toml: crates.io 非公開、コアクレートのみがタグ/Release/CHANGELOG を管理
• .github/workflows/release-plz.yml: main push → Release PR 自動作成 → マージ後タグ自動作成

3. NAPI .tgz の配布先を GitHub Pages から GitHub Releases に移行

これまで NAPI バイナリ (.tgz) は GitHub Pages にデプロイしていたが、force_orphan: true により新バージョンのデプロイで旧バージョンが消えてしまう問題があった。GitHub Releases のアセットに変更することで、バージョンごとに .tgz が保持されるようになる。

	Before	After
NAPI .tgz	GitHub Pages (force_orphan で上書き)	GitHub Releases のアセット
WASM (デモ用)	GitHub Pages	GitHub Pages (変更なし)
ダウンロード URL	https://future-architect.github.io/uroborosql-fmt/uroborosql-fmt-napi-X.Y.Z.tgz	https://github.com/future-architect/uroborosql-fmt/releases/download/vX.Y.Z/uroborosql-fmt-napi-X.Y.Z.tgz

vscode-uroborosql-fmt 側のダウンロード URL も合わせて変更が必要（別 PR で対応）。

4. CI.yml: デプロイフローの改善

• トリガー: tags: ["v*"] を追加し、タグ push 時のみデプロイ
• ジョブ分離: 旧 deploy-to-gh-pages を2ジョブに分離
  • upload-napi-to-release: NAPI .tgz を GitHub Release にアップロード（gh release upload）
  • deploy-wasm-to-gh-pages: WASM のみ GitHub Pages にデプロイ（デモページ用）
• バージョン同期: デプロイ時にタグからバージョンを取得し、NAPI の package.json を自動同期

5. ドキュメント

• docs/release-plz-migration.md: 設計の経緯・フロー・手動作業まとめ

リリースフロー: Before / After

Before（手動）

1. 開発者がコードを変更して main にマージ
2. main push で自動的に NAPI + WASM がビルド・デプロイ（GitHub Pages）
   → リリースの区切りが曖昧（main push = デプロイ）
3. リリースしたいとき、手動で全 Cargo.toml / package.json のバージョンを書き換え
4. bump up PR を作成してマージ（#214）
   → CHANGELOG なし、Git タグなし、GitHub Release なし

After（release-plz で自動化）

1. 開発者が Conventional Commits (feat: / fix: 等) でコミットし main にマージ
2. release-plz が自動で Release PR を作成
   → Cargo.toml のバージョン更新 + CHANGELOG.md 生成
3. Release PR をレビュー & マージ
4. release-plz が Git タグ (v1.0.2) + GitHub Release を自動作成
5. CI がタグトリガーで起動
   → NAPI ビルド → .tgz を GitHub Release にアップロード
   → WASM ビルド → GitHub Pages にデプロイ（デモ用）

比較

	Before	After
バージョン更新	手動で全ファイル書き換え	release-plz が自動更新
CHANGELOG	なし	自動生成
Git タグ	なし	自動作成 (v1.0.2)
GitHub Release	なし	自動作成
デプロイ契機	main push（毎回）	タグ push（リリース時のみ）
NAPI 配布先	GitHub Pages（上書き）	GitHub Releases（バージョンごとに保持）

マージ前の TODO

• PAT の作成と登録 — Classic PAT を repo スコープで作成し、リポジトリの Secrets に RELEASE_PLZ_TOKEN として登録する。デフォルトの GITHUB_TOKEN で作成したタグは他のワークフローをトリガーしないため必須。Fine-grained PAT はリポジトリ単位で権限を絞れるが、組織に所属していないと Resource owner に組織を指定できないため Classic PAT を使用する。
• Conventional Commits の運用開始（推奨） — feat: → minor, fix: → patch, feat!: → major。従来のコミットも patch として扱われるため段階的に移行可能。

検討事項

• CLI バイナリも GitHub Release に含めるか — 現時点では NAPI .tgz のみ。需要が出たら追加する。
• PAT の代わりに GitHub App を使うか — PAT は個人アカウントに紐づくため、作成者が退職するとトークンが無効化されるリスクがある。GitHub App は組織に紐づくため長期運用に適しているが、組織の Owner 権限がないと作成できない（現時点では権限なし）。また、vscode-uroborosql-fmt でも既に VSCE_PAT（個人 PAT）を使用して VS Code Marketplace への公開を行っており、PAT 運用の前例がある。後から GitHub App に切り替え可能なので、一旦 PAT で運用を開始する。
• Conventional Commits を PR タイトルで強制するか — 今回は保留。段階的に運用を定着させてから検討する。

マージ後の TODO

• 初回タグの作成 — この PR のマージコミットに v1.0.1 タグを打つ。release-plz は最後のタグ以降のコミットから CHANGELOG を生成するため、タグを打つことで以降の純粋な機能変更だけが CHANGELOG に載るようになる。

  git tag v1.0.1 main
  git push origin v1.0.1

• vscode-uroborosql-fmt 側の対応 PR をマージする — feat: uroborosql-fmt NAPI バージョンの自動更新 vscode-uroborosql-fmt#103

変更ファイル

ファイル	操作
Cargo.toml	修正: version = "1.0.1" を [workspace.package] に追加
crates/*/Cargo.toml (4ファイル)	修正: version.workspace = true に変更
.github/workflows/CI.yml	修正: タグトリガー追加、デプロイを2ジョブに分離
release-plz.toml	新規: release-plz 設定
.github/workflows/release-plz.yml	新規: release-plz ワークフロー
docs/release-plz-migration.md	新規: 設計ドキュメント

[tanzaku]

uroborosql-fmt のリリースプロセスやバージョニングは課題に感じていたので改善されて嬉しいです！
以下少し気になった点を記載します。

CLI バイナリのリリース

CLI バイナリも GitHub Release に含めるか — 現時点では NAPI .tgz のみ。需要が出たら追加する。

CLI バイナリも GitHub Release に含めるのが良いと思います。
「あれば使うが、無くても要望は出さない」層が大半なので、「あれば使う」人を取りこぼさない為に事前に用意しておくという考えです。
（もちろん、かかる工数を考えたうえでやらないという判断はあると思うので、最終的にどうするかはお任せします）

release-plz/action のサプライチェーン攻撃対策

release-plz/action は強い権限の PAT を扱うため、サプライチェーン攻撃を受けた場合の影響範囲が大きそうです（不正なリリース作成 → VSCode 拡張への波及など）。
可能性は低いと思いますが念のために、ドキュメント (https://release-plz.dev/docs/github/security#-solution-pin-the-action-version) でも書かれている通り、release-plz/action@v0.5 のタグ指定をコミットハッシュ指定に変更した方が良いかと思いました。

Github Actions のバージョン指定について

CI.yml で使われている actions/checkout や actions/setup-node のバージョンを見ると v3 とv4 が混在しているようですが、特に理由が無ければ統一はしておきたいです。
また actions/checkout@v4 は node20 を利用しており、node20 は 2026/04/30 で EOL のようなので、こちらも計画的に上げていきたいですね（この PR で一度にやる必要はないと思いますが）

[ppputtyo]

@tanzaku
ご指摘ありがとうございます。

CLI バイナリのリリース

CLI バイナリも GitHub Release に含めるか — 現時点では NAPI .tgz のみ。需要が出たら追加する。

CLI バイナリも GitHub Release に含めるのが良いと思います。
「あれば使うが、無くても要望は出さない」層が大半なので、「あれば使う」人を取りこぼさない為に事前に用意しておくという考えです。
（もちろん、かかる工数を考えたうえでやらないという判断はあると思うので、最終的にどうするかはお任せします）

CLIバイナリの命名規則、アーカイブ形式などの決定が必要なので、別PRで対応しようと思いますがよろしいでしょうか？

release-plz/action のサプライチェーン攻撃対策

release-plz/action は強い権限の PAT を扱うため、サプライチェーン攻撃を受けた場合の影響範囲が大きそうです（不正なリリース作成 → VSCode 拡張への波及など）。
可能性は低いと思いますが念のために、ドキュメント (https://release-plz.dev/docs/github/security#-solution-pin-the-action-version) でも書かれている通り、release-plz/action@v0.5 のタグ指定をコミットハッシュ指定に変更した方が良いかと思いました。

コミットハッシュ指定に変更しました。

-        uses: release-plz/action@v0.5
+        uses: release-plz/action@1528104d2ca23787631a1c1f022abb64b34c1e11 # v0.5

https://github.com/release-plz/action/commits/v0.5

Github Actions のバージョン指定について

CI.yml で使われている actions/checkout や actions/setup-node のバージョンを見ると v3 とv4 が混在しているようですが、特に理由が無ければ統一はしておきたいです。
また actions/checkout@v4 は node20 を利用しており、node20 は 2026/04/30 で EOL のようなので、こちらも計画的に上げていきたいですね（この PR で一度にやる必要はないと思いますが）

v4に統一しました。actions/checkout@v4 のEOLの件も承知しました。別PRで対応します。

2ffead1