カレンダーバージョニングにする

[syuilo]

Summary

• 実際は全く異なるのにフォークとメジャーバージョンが同じになる場合があるのは混乱を招きそう
• 逆にフォークの方が新しいメジャーバージョンを採用した場合、内容的にはMisskeyの方が新しくてもフォークの方が新しいように見えてしまい混乱を招きそう
• そもそもメジャーバージョン.マイナーバージョン.パッチバージョンという形式のバージョニングを採用することの意義が薄い

[syuilo]

やるとしたら YYYY.MINOR.PATCH か YYYY.0M.PATCH かな

[syuilo]

ref. https://calver.org/

[syuilo]

YYYY.MINOR.PATCHにするか

[Mogyuchi]

YYYY.MINOR.PATCH と一口に言っても MINORが0始まりか1始まりかの違いがあるっぽいですね。
calver.orgで例示されている プロジェクトでも pip・boltons では 0 で始めていますが、Unity・PyCharm では 1 で始めています。

（MINORという呼称 semverのそれと混ざって一瞬訳わからなくなるな）
fyi: 時雨堂さんでは 1 始まりにしていて YYYY.RELEASE.FIX と呼称しているようです。
https://github.com/shiguredo/oss#バージョン番号について

[acid-chicken]

せっかくなのでもうちょっと包括的な提案なんだけど月次リリース（YY.MM.PATCH）にしてしまうのはどうだろう
月次リリースになるとそれに従ってスケジュールもある程度固定化できるが、レビュースケジュールがあらかじめ分かっているとよりレビューしやすいし、リリース時期が明確になるのは運用者も嬉しいと思う

例えば第三日曜でそのリリースに入れる機能の受付を締め切ってリリース用ブランチを切り、レビュー期間に入って第四土曜以降に最初のリリースを行い、そこから二つ次のリリースをするまでの間当該ブランチにバグフィックスのみ入れ続けるようにする（第三日曜以降の機能はそれはそれとして develop に取り込まれ次の月に持ち越される）。
新機能を早く取り入れたい運用者は最新リリースを使うことでその目的を達成でき、安定した運用を重視したい運用者は新リリースが出た時点で一つ前の月の最新パッチバージョンを使うことで、人海戦術的に洗い出されたバグが対処されたリリースを使うことができ、ある程度安定性を担保できる。

[syuilo]

YOSASOU

あと細かいけどYYではなくYYYYの方が良いと思った(カレンダーバージョニングであるということが視覚的にも分かりやすいと思ったため)

[acid-chicken]

あと細かいけどYYではなくYYYYの方が良いと思った(カレンダーバージョニングであるということが視覚的にも分かりやすいと思ったため)

まあそんなにこだわりはない（4 桁って長くねってなる程度）

[acid-chicken]

YOSASOU

@syuilo 今の develop とりあえず 23.05.0 としてリリースしようぜ

[syuilo]

もうちょい寝かせたい感

[acid-chicken]

把握

[acid-chicken]

13.13.0 とかその今後のリリースってなんか予定決めてたりする？

[syuilo]

特に考えてないかも

[syuilo]

13.14.0のリリース終わったらやろうかな

[acid-chicken]

リリースサイクルとかどうする？

[syuilo]

決めてもなんとなくそれに則って運用できる気がしないから「カレンダーバージョニングにする」以外はひとまずやらないかも

[syuilo]

まあYY.MM.PATCHにするなら1か月ごとリリースという感じにはなりそう

[syuilo]

する

[tamaina]

リリースサイクルとかどうする？

1回のリリースの負荷を削減するには週次もしくは2週おきがいいと思う