テーマ： release-management
-
Tags and releases: lightweight versus annotated tags and how they travel
A lightweight tag is only a name for a commit; an annotated tag is an object with tagger, date, message and optional signature, which is why git describe ignores lightweight tags by default and why releases should use annotated or signed tags; tags are not pushed with branches unless --follow-tags or --tags is used, and a published tag should never be moved.
-
Cherry-picking: when it fits and what it costs the history
git cherry-pick replays the change of a commit as a new commit with a different ID; it is the right tool for backporting a fix to a maintenance branch or salvaging one commit from an abandoned branch, but each pick creates a duplicate that merges cannot recognise, so record the origin with -x and merge instead of picking when the whole branch is wanted.
-
小規模プロジェクトのリリース周期：定期リリース列車と準備が整ってからのリリース
バージョン番号はリリースが何を約束するかを示し、周期の方針はいつリリースするかを示す。Rust は nightly、beta、stable の列車で六週間ごとに安定版を出し、Python は PEP 602 で年一回の機能リリースへ移行した。Django は機能リリースを定期的に、パッチを必要に応じて出す。小規模プロジェクトも、機能は日程または目立った変更の蓄積に合わせ、パッチは修正が取り込まれるたびに出すという形を取り入れられる。
-
Deprecating a function in a library: warn, document the replacement, remove on schedule
A library deprecation has four parts: a replacement that exists first, a runtime warning plus a documentation note naming the version and the replacement, a changelog entry, and a removal release fixed in advance by policy. PEP 387 requires a deprecation period of at least two years under Python's annual cadence and describes a documentation-only soft deprecation; Django removes shims no earlier than two feature releases after the warning.
-
Conventional Commits：機械可読なコミットの種類
Conventional Commits 仕様は、コミットメッセージに種類を示す接頭辞（feat、fix など）と破壊的変更の印を加えます。これにより、変更履歴やバージョンの繰り上げを自動的に導き出せます。
-
セマンティックバージョニング：バージョン番号が約束すること
Semantic Versioning 2.0.0 は MAJOR.MINOR.PATCH に互換性の約束を込め、プレリリースとビルドメタデータの接尾辞を定義します。公開 API が宣言されている場合にのみ機能します。
-
API のバージョニング：互換性を壊す時期と方法
多くの変更は機能の追加で対応できる。新しいメジャーバージョンは、サポート対象を倍増させる最後の手段である。バージョンはパスまたはメディアタイプに含め、互換性のルールを文書化し、削除の前に非推奨を告知する。
-
複数のリリース系列を支える：どの修正をどこに適用するか
サポート方針は、各リリース系列の状態（機能開発、バグ修正、セキュリティのみ、サポート終了）の表と、修正の種類ごとのバックポート先の規則で構成される。Pythonは系列に2年間のバグ修正リリースと、その後3年間のセキュリティのみのリリースを提供する。Djangoは重大な修正を直近の機能リリースに、安全性とデータ損失の修正を直近2つと長期サポート系列に戻す。Rustは最新の安定版のみを支える。小規模プロジェクトは表を公開し、守れる最小限の約束を標準とすべきである。
-
人のための変更履歴を維持する
変更履歴は、バージョンごとの注目すべき変更を選び、時系列に並べた一覧である。Keep a Changelog は、小さな構成（Added、Changed、Deprecated、Removed、Fixed、Security）と Unreleased セクションを定めている。
機械可読： JSON