generated at
Keep a Changelog
towncrierで生成するCHANGELOGの「中身」までは規約がないなあと思っていたら、CHANGELOGの規約と呼べそうなものを見つけた。semver12factorと同様に、主張の1つでしかないものの、内容は良さそうなので、従っておいて良いと思う。

またこの規約は、既存のCHANGELOGの規約 Style of Change Logs (GNU Coding Standards) が「標準とは呼べない、内容も不十分」としている。

> 基本理念
> 変更履歴は機械のためではなく人間のためにあります。
> バージョンごとに作成する必要があります。
> 同じ種類の変更をグループ化する必要があります。
> バージョンとセクションはリンク可能である必要があります。
> 最新バージョンは先頭にきます。
> 各バージョンのリリース日を表示されます。
> Semantic Versioning に従っているかどうか言及してください。
> 変更の種類
> Added 新機能について。
> Changed 既存機能の変更について。
> Deprecated 間もなく削除される機能について。
> Removed 今回で削除された機能について。
> Fixed バグ修正について。
> Security 脆弱性に関する場合。
若干機械翻訳っぽいな、と思ったら 日本語訳はGoogle翻訳を使ったらしい 。気になるなら修正提案すればよいかな。


> VS Code の拡張作っている際に CHANGELOG.md が自動生成され、書き方はKeep a Changelogに従えと書かれていたので紹介する。
> ここに書かれていることは絶対ではなくただ提案しているだけである。意見がある人は話し合おうという温度感っぽいので、納得いかない場合は issue 立てると良いと思う。
> 僕自身はなんでもよくてある程度型が欲しかっただけなのでこれからはこれに従って書いていこうと思う。ただまぁ Semantic Versioning もそうだけどちゃんと従おうとすると以上にだるくなってくるので雰囲気従うくらいだと思う。
>
> CHANGELOG の原則
> 機械的に生成するのではなく人間の手で書く
> 各セクションへのリンクが容易にできる
> 1つのバージョンごとに1つのサブセクションを作る
> リリースは新しいものが上に来るようにする
> 日付のフォーマットは YYYY-MM-DD で書く
> Semantic Versioning に従うかは明示的に表明する
> 各バージョンのセクションは次の原則に従うべき
> 上記のフォーマットの日付を付与する
> 以下のようにグループ分けして表記する
> Added 新機能
> Changed 既存機能の変更
> Deprecated 将来的に削除される機能
> Removed 削除された機能
> Fixed バグフィックス
> Security 脆弱性修正のためユーザーにアップデートを促す場合

towncrierを使うことで、上記のルールに自然に従うことになるので、あとは細部を調整すればあまり手間を増やさずに対応できる。