こんにちは
あっという間に年度末で、また今年も桜の季節がやってまいりました
Gitにおけるリリースのバージョン、SemVerの復習で今回blogにメモしようと思います
# Semantic Releaseを支える「SemVer（セマンティックバージョニング）」
むしろ、
> 「Semantic Release = SemVerを自動で運用する仕組み」
と言っても過言ではありません。
本記事では、SemVerにフォーカスして、
– バージョン番号の意味
– なぜ重要なのか
– Semantic Releaseとの関係
を整理していきます。
—
## SemVerとは？
SemVer（Semantic Versioning）は、ソフトウェアのバージョン番号に意味を持たせるルールです。
基本構造は以下の通りです。
MAJOR.MINOR.PATCH
1.4.2
| 要素 | 役割 | 具体例 |
|——–|——|——–|
| MAJOR | 破壊的変更 | APIの互換性が壊れる |
| MINOR | 機能追加 | 新機能追加（後方互換あり） |
| PATCH | バグ修正 | 不具合修正 |
—
## 具体例で理解するSemVer
### 例1：バグ修正
1.4.2 → 1.4.3
—
### 例2：機能追加
1.4.2 → 1.5.0
—
### 例3：破壊的変更
1.4.2 → 2.0.0
—
## なぜSemVerが重要なのか？
### 1. 利用者が安心できる
ユーザーはバージョン番号を見るだけで、
– 安全なアップデートか
– 影響があるか
を判断できます。
—
### 2. 依存関係管理がしやすい
例えばnpmでは以下のように指定できます。
“`json
“library”: “^1.4.0”
これは、
「1.x系ならOK（ただし破壊的変更はNG）」
という意味になります。
### 3. チーム開発での共通言語になる
といった形で、変更の重さを共通認識できます。
## Semantic Releaseとの関係
Semantic Releaseは、SemVerのルールを自動適用するツールです。
流れ
## Conventional Commitsとの連携
Semantic Releaseは、以下のようなコミットからSemVerを判断します。
例
判定ルール
| コミット | バージョン |
|---|---|
| feat | MINOR |
| fix | PATCH |
| BREAKING CHANGE | MAJOR |
## 実際のバージョン決定フロー
現在のバージョン: 1.4.2
コミット:
– fix: バグ修正
– feat: 新機能追加
→ 次のバージョン: 1.5.0
※ 複数ある場合は「最も大きい変更」が優先されます
## よくある誤解
誤解1：とりあえずバージョン上げればいい
👉 NG
SemVerは「意味を持たせる」ことが重要です。
誤解2：MAJORはめったに使わない
👉 半分正解・半分間違い
誤解3：PATCHでも何でも入れていい
👉 NG
PATCHはあくまで「バグ修正のみ」
## 運用のコツ
### 1. 破壊的変更は明示する
または
### 2. コミット粒度を揃える
### 3. 「利用者視点」で判断
## まとめ
SemVerは単なるバージョン番号ではなく、
「変更の意味を伝えるための言語」
です。
そしてSemantic Releaseは、
その言語を自動で運用する仕組み
です。
この2つを組み合わせることで、
が実現できます。
入会申込
ログイン
