toml11 v3.0.0リリース

毎回思うんだけどどういうタイミングでリリースタグ打てばいいのかよくわからない。皆どうしてるんだろう。

github.com

基本的に前回記事を書いた時からそんなに変わっていない。一応自分で使ってみて気になった細かなことがいくつかあるが(例えばカスタムシリアライザを書いてるときにtoml::stringがただの文字列として(特殊文字エスケープとかがされずに)出力されたのにちょっと困った、など)、それ以上のことはない。

元々以前と同じテストに通っていたので、リリースするかしないかが完全に気分の問題になっていた。いや一応自前のツールのいくつかで使ってみてはいたけれど……。ちなみに今日は、「最初から完璧にするのは無理だしタグ打たないよりは打って変なこと見つかったらパッチバージョン上げるか」くらいの気持ちで出した。一応外部のエッジケース詰め合わせテストにはかけているし、個人でそれ以上の秘孔を突ける気があんまりしなかった。

しかしリリースのタイミングは結構困る問題だ。toml11は完全に気分でリリースしているが、自作のアプリケーションの一つでは、月イチでリリースすると決めているものもある。そっちでは追加すべき機能が無限にあるので、間に合った分だけマージしていくという作戦だ。バグ修正があればこのスケジュールに則らずにリリースするが、一ヶ月おき以外では新機能は追加しない。こうすることで「もうリリースしていいかな……いや見つけてないエッジケースがあるかも……テストももっとできるといえばできるし……」みたいなことをいちいち悩まなくて済む。バグがあれば明記してパッチバージョンを上げればいい。最初からありとあらゆるエッジケースを塞ぐなんて無理だ。「Done is better than perfect(多分動くと思うからリリースしようぜ)」だ!

だがこの月イチ作戦は困ることもある。ブランチが増えまくって頭が混乱してくることだ。というのも、topicブランチを一度リリース用のブランチ(今回はmaster)にマージしてしまうと、いざバグを見つけた時バグ修正のみのはずのリリースに新機能が混ざってしまうので、topicブランチが次のリリースまで生えまくるからだ。パッチリリース前にrevertrebaseで履歴を改ざんすればいいのだが、地味に手間なのでPRの時以外はやりたくない(PRの時は色々試した後最初から全部知ってたみたいな最小ステップのコミット履歴に改ざんしてカッコよく仕上げることはある。なぜならカッコいいから。あとノイズは減ったほうがレビューが楽だと思うので)。となると、topicブランチで開発し、そこでバグを見つけたらhotfixからmasterにマージし、開発が一段落したらtopicブランチはマージせずに次の機能に行く、という流れになる。なので未マージのブランチが増えてしまう。というわけで混乱する。何で個人開発なのにこんなにブランチあるんだ? たまにconflict解消とかしてるし……全部自分で書いてるのに……。

色々考えてみたのだが、この場合、多分nightlyとかdevelopみたいな感じの名前のpre-releaseブランチを作って、新機能が一段落したらそこにマージしていき、変なことが起きないか確認していって、リリースの時はそれを一気にmasterにマージする、万一topicブランチを次のリリースに入れないことが決まったら、それをdevelopから消して、topicブランチは後のリリースでまた試すために残す、みたいなことをすればちょっと楽になる。ここまで書いて思ったが、これはまんまgit-flowだな……。周回遅れで車輪を再発明してしまった……。

postd.cc

正直、この手のややこしいブランチ操作が必要になるのは古いバージョンにもパッチを当てていく必要が生じるような超大規模プロジェクトだけだと思っていた。例えばプログラミング言語とかだと、特殊な事情によって古いバージョンを使い続けるしかない人がたまにいて、そういう人たちのために古いバージョンの処理系にセキュリティパッチなどが当てられたりなんかしている。そういう場合、例えばv3を出してからも2系をサポートしていく意味はあるし、それにはブランチを切るのが適切だ。だが私のライブラリやアプリケーションにはそういうことは必要無いのでブランチもややこしくならない……はずだった。だが必ず月イチで新機能追加をリリースすると決めるとこういうことになるとは。何事もやってみるまでわからんものですね。

そういうわけで、「toml11でも月イチとかでリリースすると決めようかな?」という気持ちは結構萎えた。加えて、toml11はそれなりにもう色々済んでいて、そんなにたくさんやりたいことがあるわけではないのだ。細々としたことは残っているが、それらは正直なくても(私の使用状況では)そこまで困らないものと、非常に面倒なのに見返りは小さいせいで単純にやりたくならないことばかりだ。リファクタリングなんかはあるかも知れないが、そういう変更はパッチバージョンにしかならない。なので一ヶ月に一回マイナーアップデートするとなると、「前回と同じ」みたいなアップデートが増えかねない。そんなアップデートはする意味がない。

というわけでtoml11のリリーススケジュールは現状維持、つまり今まで通り何か修正やアップデートがあり次第、ということにした。ちなみにPRをマージすると、「早めにリリース版に名前書いておいた方がいいよな……」となってパッチでもマイナーでも自分で入れた変更しか無いときに比べてリリースが早まります。バグを見つけたら見限らずにPR送ってくれると比較的早めに対応しますよ。あと海外の人はともかく日本人っぽい人まで英語でIssueとか書いてるけど、日本語英語両方対応できるので、そこも気にしなくていいです。というのも私は英語より日本語のほうが得意だからです。誰が見てるかわからんので一応書いといた。

そういうわけでメジャーアップデートも一回区切りだ。しばらくは別の仕事だな。