CHANGELOGが毎度conflictするのが煩わしい

[FineArchs]

Summary

行を追加しているだけなのにどういう訳か頻繁に衝突して、主にPR用ブランチの最新版追従が面倒です。

• CHANGELOGの内容はPRに書いておいて、メンテナがマージ直前に書き込みを行う（またはマージ直後にgithub actionsで追記）
• CHANGELOGの内容は/changelogs/下にそれぞれ別のファイルとして置いておいて、リリース直前にまとめて追記

のいずれかのような仕組みがあるとこちらは楽です。

Purpose

リリース直後名物の2023.XX.XX増殖現象や時空の歪みも防げると思います。

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[anatawa12]

行を追加しているだけなのにどういう訳か頻繁に衝突して、

これはadd-addのコンフリクトはどっちを先に追加するかの問題になるためコンフリクト扱いされるのですよね。

主にPR用ブランチの最新版追従が面倒です。

正直changelogだけのコンフリクトは我々側でresolveしてマージできるからそれでいい気もする

リリース直後名物の2023.XX.XX増殖現象や時空の歪みも防げると思います。

はそもそもリリースしたときに次のバージョン用のテンプレートをdevelopに追加するべきな気がするけどそこらへんは #13075 あたりでやるべきなのかも

[acid-chicken]

changelog-drafts/general/item1.md みたいな感じなファイルを各自作ってもらうようにしてリリース時に cat すればよさそう

[samunohito]

もしこれが採択された場合、CHANGELOG.mdの記入箇所チェックが役割を終えるので消しておきたい

• https://github.com/misskey-dev/misskey/blob/develop/.github/workflows/changelog-check.yml
• https://github.com/misskey-dev/misskey/tree/develop/scripts/changelog-checker

ああいや結局記入位置を間違える問題はついて回りそうかな…蒸気は最終的な形次第で

[anatawa12]

catする案、順番が実装順と関係なくなったりして少し気持ち悪くなりそうな気もする...
あとは未リリースの変更点がパット見でわかりづらくなるのも好きではない

プルリクのコメントに書いといてGitHub actionsに任せる等でchangelogを更新していく形式のほうがいいと思ってます(それこそマージ自体をGitHub actions等に任せる形とか)

(https://keepachangelog.com/en/1.1.0/#effort People can see what changes they might expect in upcoming releases)

[FineArchs]

CHANGELOGの自動更新はコミット履歴の汚染が気になるかも？

[anatawa12]

私の想定ではSquih mergeの直前にgithub actionsがupstreamのmergeとchangelogに追記してsquish mergeするのを想定してたのでコミット履歴の数は増えない想定でいました

[FineArchs]

それだとmemberによるコードの編集が禁止されたPRで実行不可能になってしまいそうな気がします