第3部 出す · 第7回 / 全12回 · 10分くらい
出す手順を道具にする。版の番号・変更の記録・確かめる一覧
出す作業には、版の番号を付ける、変更を書く、組み立てる、確かめる、配る、といった地味な手順が並びます。1回ずつ手でやると重く、だんだん出すのが億劫になります。この回では、その手順を決まった形にして、何度でも同じように出せる道具にします。
履修 0 / 12 回
この回を読み終えると、できるようになること
- 版の番号の付け方（セマンティック バージョニング）を説明し、変更の種類に合わせて番号を決められる
- 変更の記録（CHANGELOG）を、読む人のために書ける
- 出す前に確かめる一覧を作り、その一部をスクリプトとAIに任せられる
専門用語は、初めて出たところで括弧に短い説明を付けています。説明が長くなるものには ※番号を付け、ページの終わりの用語メモにまとめました。
1版の番号には決まった付け方がある
版の番号は、セマンティック バージョニング※1という決まりで付けるのが一般的です。番号を「メジャー.マイナー.パッチ」の3つに分けて、変更の種類で上げる場所を決めます。
| 上げる場所 | いつ上げるか | 例 |
|---|---|---|
| メジャー（1.x.x → 2.0.0） | 前の版と使い方やデータの形が変わり、そのままでは移れないとき | 保存の形式を作り直した |
| マイナー（1.2.x → 1.3.0） | 前の版のまま使える形で、機能を足したとき | 書き出しの機能を足した |
| パッチ（1.2.3 → 1.2.4） | 前の版のまま使える形で、不具合を直したとき | 保存に失敗する不具合を直した |
番号を見ただけで「入れ直して大丈夫か」がわかるので、使う人が安心して更新できます。最初に出すときは 0.1.0 や 1.0.0 から始めます。
2出した版に、git のタグを付ける
版を出したら、その時点に git のタグ（v1.2.4 など）を付けます。タグがあると、あとで不具合の報告が来たときに、その版のコードにすぐ戻って調べられます。
逆に言えば、タグが1つも無いリポジトリは、「どの時点を出したのか」が決まっていない状態です。第1回で、自分のリポジトリにタグが1つも無かったと書きましたが、それは出したことがないのと同じ意味でした。
# 出す版にタグを付けて、GitHub にも送る
git tag -a v1.0.0 -m "最初の公開版"
git push origin v1.0.03変更の記録は、使う人のために書く
版ごとに何が変わったかを、変更の記録（CHANGELOG※2）に書きます。「Keep a Changelog」という書き方の指針では、変更の記録は機械のためではなく人のために書くもので、新しい版を上に置き、変更を「追加・変更・非推奨・削除・修正・セキュリティ」の種類に分けて書くことを勧めています。
git のコミットの一覧をそのまま貼るのではなく、使う人から見て何が変わったかを書きます。「saveData の例外処理を修正」ではなく「保存に失敗することがある問題を直しました」です。
4出す前に確かめる一覧を作る
出すたびに確かめることを、一覧にしておきます。たとえば次のようなものです。
- テストがすべて通る
- 版の番号を上げた（アプリの中の表示も）
- 変更の記録を書いた
- 新しい環境（別のユーザー、別の Mac）で、入れて開けた
- 前の版のデータを読み込めた（データを失わない）
- 署名と公証が通った（直接配布の場合）
一覧があると、出すたびに考えることが減り、抜けも減ります。この一覧が、第4回で書いた「完成の条件」の、毎回版です。
5一覧の多くは、スクリプトとAIに任せる
一覧のうち、決まった手順で確かめられるもの（テスト、番号、組み立て、署名）は、スクリプトにまとめて1つのコマンドで走らせます。変更の記録の下書きは、コミットの一覧を渡して「使う人から見た変更に書き直して」とAIに頼めます。
人が確かめる必要があるのは、「新しい環境で開けたか」「前のデータを読めたか」のような、実際に触ってみないとわからない部分だけです。
組み立ての手順には、思わぬ落とし穴もあります。自分は、アプリのインストール用ファイル（DMG（Mac でアプリを配るときによく使う、ディスクの形をしたファイル））を作る手順が、Finder と競合して失敗することがありました。一度直し方がわかったら、スクリプトに書き込んでおけば、次からは同じことで悩みません。
誤解よくある思い違い
版の番号は、気分で上げてよい
決まりに沿って付けると、番号を見ただけで「そのまま更新して大丈夫か」が伝わります。データの形が変わったらメジャーを上げます。
変更の記録は、コミットの一覧で十分
コミットは作る人のための記録です。使う人から見て何が変わったかを、種類ごとに書き直します。
演習手を動かして確かめる
演習1
今の版は 1.4.2 です。次の変更をまとめて出すとき、次の版の番号は何になるでしょうか。
- 書き出しの形式に CSV を足した
- 起動が遅い問題を直した
また、保存の形式を変えて、古い版のデータをそのままでは読めなくなった場合はどうでしょうか。
答えを見る
機能の追加（前の版のまま使える）があるので、マイナーを上げて 1.5.0 です（パッチは0に戻します）。
保存の形式を変えて古いデータを読めなくなるなら、メジャーを上げて 2.0.0 です。ただし、その場合は「古いデータを新しい形式に移す仕組み」を必ず用意します（第8回）。データを失う版は出しません。
頼み方そのまま使える頼み方の例
次のアプリを出すための「出す前に確かめる一覧」と、それを走らせるスクリプトの案を作ってください。
- 一覧は、スクリプトで確かめるもの・AIに頼むもの・人が確かめるものに分ける
- データを失わないための確認（前の版のデータを読めるか）を必ず入れる
- 版の番号はセマンティック バージョニングで決め、タグを付ける手順を入れる
まだ何も実行せず、案だけ出して止まってください。
アプリ：（言語・組み立て方・配り方を書く）用語メモ本文の ※番号の説明
出典確かめた資料（2026年10月時点）
- セマンティック バージョニング 2.0.0 メジャー・マイナー・パッチの上げ方。
- Keep a Changelog 1.1.0 変更の記録は人のために書く、新しい版を上に、変更を種類で分ける。