Version bump

Version Bump スキル

コアコンセプト: テンプレートバージョンのベストプラクティス

候補	推奨	理由
初回 commit（スキャフォールド）	✗	不完全、デモデータ混在、受け取った人が使えない
MVP（最初の機能完成版）	✓	受け取った人がすぐ使える、最小限の動作保証
常に最新安定版	△	最新だが変更頻度が高いとテンプレートが不安定

テンプレートを変えるタイミング: MAJOR バンプ / テンプレートの大幅刷新時のみ。
日常リリースは「前バージョン → 差分適用」が基本。

---

Step 1: プロジェクトタイプを検出

以下の順で確認し、最初にマッチしたものを採用:

検出条件	プロジェクトタイプ	バージョン取得元
scripts/bump-version.py が存在	カスタム（VBA/Excel 等）	M00_Constants.bas の APP_VERSION
package.json が存在	Node.js/npm	version フィールド
pyproject.toml または setup.cfg が存在	Python (PEP 517)	version フィールド
Cargo.toml が存在	Rust	version フィールド
VERSION または TEMPLATE_VERSION ファイルが存在	汎用	ファイル内容

---

Step 2: バンプ種別を判断

ユーザーが major/minor/patch を明示しない場合、git diff HEAD~5 を読んで提案する:

変更の性質	バンプ種別	例
新機能追加（API・ボタン・モジュール）	minor	出欠ボタン追加
バグ修正・ドキュメント	patch	タイポ修正
後方非互換な変更（列削除・シート廃止）	major	PrintSheet 列削除

MAJOR は必ず確認ダイアログを表示してから実行すること。

---

Step 3: ドキュメント更新（バンプと必ずセット）

黄金律: コードが変わったらドキュメントも変わる。 バージョンバンプはコードとドキュメントの同時リリース。 CHANGELOG の [Unreleased] が空のまま bump するのは禁止。

バージョンバンプを実行する前に、変更内容に応じて以下を更新する。 これを怠ると「コードは新しいがドキュメントは古い」状態になり、利用者・開発者・保守担当の全員が混乱する。

Category B: バンプ前に必ず更新（全バンプ共通）

1. CHANGELOG.md の [Unreleased] セクション

   • 変更した機能・バグ修正を箇条書き
   • 見出し: ### Added（新機能）/ ### Fixed（修正）/ ### Changed（非互換変更）
   • bump-version.py が自動で新バージョンセクションに変換する

2. 実装ステータス管理ファイル（プロジェクトにあれば）

   • VBA: specs/FeatureList.md のステータス（未着手 → 一部実装 → 実装済）
   • 一般: README の機能表、ロードマップ等

3. TODO / タスク管理

   • 完了タスクに [x]、次バージョンのタスクを追加

Category C: 機能変更時に更新（MINOR / MAJOR）

4. セットアップ・インストール手順

   • VBA: IMPORT_INSTRUCTIONS.md, docs/初期設定マニュアル.md
   • 一般: README.md の Installation、docs/setup.md
   • 新モジュール・新依存・手順変更を反映

5. 開発参加ガイド

   • CONTRIBUTING.md: 新スクリプト・新ワークフロー・ディレクトリ構成

6. ユーザー向けマニュアル

   • 新機能の操作手順、変更された UI（ボタン・メニュー）
   • 「準備中」表記を実装済みに更新

Category D: 随時

7. 意思決定ログ / 設計ドキュメント
   • PLAN.md 等に大きな設計判断を記録

バージョン文字列の横断更新

ドキュメント内のバージョン参照（v0.4.0 → v0.5.0、フッターの「対応バージョン」等）を grep で洗い出して一括更新する:

grep -rn "v0\.4\.0\|komagumi_base_v0\.4" docs/ *.md

---

Step 4: バージョンバンプを実行

カスタム（scripts/bump-version.py がある場合）

python3 scripts/bump-version.py <major|minor|patch> "<description>"
# MVP 到達時（最初の機能完成版）はテンプレートも更新
python3 scripts/bump-version.py minor "Sprint A完了" --set-template

自動で行われる処理:

1. バージョン定数（APP_VERSION 等）を更新
2. ビルド実行（build-sjis.sh 等）
3. 新バージョンアーティファクト（xlsm 等）を生成
4. 旧バージョンアーティファクトを archive/ に移動
5. CHANGELOG.md に新セクション追記
6. --set-template 時: TEMPLATE_VERSION ファイルを更新

Node.js/npm

npm version <major|minor|patch> -m "bump: %s - <description>"

追加で行うこと:

• CHANGELOG.md を手動または conventional-changelog で更新
• git tag は npm version が自動作成

Python (pyproject.toml)

# pyproject.toml の version フィールドを更新
[project]
version = "X.Y.Z"  # ← 手動またはスクリプトで更新

git tag vX.Y.Z

汎用（VERSION ファイル）

echo "X.Y.Z" > VERSION
# CHANGELOG.md を手動更新
git tag vX.Y.Z

---

Step 5: CHANGELOG.md フォーマット

Keep a Changelog 形式を採用:

## [X.Y.Z] - YYYY-MM-DD

### Added      ← minor バンプ（新機能）
- 新機能の説明

### Fixed      ← patch バンプ（バグ修正）
- 修正内容の説明

### Changed    ← major バンプ（後方非互換な変更）
- 変更内容の説明

---

Step 6: 完了確認チェックリスト

コード/成果物:

• バージョン定数（APP_VERSION / package.json 等）が更新されている
• ビルドアーティファクト（xlsm / dist / build 等）が新バージョンで生成されている
• 旧バージョンアーティファクトが archive/ または git タグで保管されている
• --set-template / MVP 指定時: TEMPLATE_VERSION が更新されている

ドキュメント（コードとセット）:

• CHANGELOG.md に新セクションが追加され、変更内容が箇条書きされている
• 実装ステータス（FeatureList 等）が最新化されている
• TODO の完了タスクにチェックが入っている
• （機能変更時）セットアップ手順・操作マニュアルが最新の機能を反映している
• ドキュメント内のバージョン参照（フッター・対応バージョン表記）が新バージョンになっている

---

参考: xlsm プロジェクトのファイル構成

excel-vba/
├── TEMPLATE_VERSION            ← テンプレートバージョン番号
├── komagumi_base_v0.5.0.xlsm   ← ゴールデンマスター（削除禁止）
├── komagumi_base_v0.6.0.xlsm   ← 現行バージョン（1ファイルのみ）
├── archive/
│   ├── komagumi_base_v0.4.0.xlsm
│   └── komagumi_base_v0.5.0.xlsm
└── scripts/
    ├── bump-version.py
    └── setup-worksheet.py