中小規模のOSSにおけるバージョニング戦略について

TL;DR

• 互換は壊すな！…なるべく
• メインラインに手を入れ続けることが最優先
  • 複数バージョンをきちんとメンテしようなどとはゆめゆめ思うべからず

本編

OSSのバージョニングについての個人的な意識について書きます。「中小規模」というのは、個人の趣味だったり、企業でやっていたりしてもそんなにリソースをかけられない場合くらいの規模感、つまり僕自身がメンテナンスに関わっているようなソフトウェアの規模感でもあります。とは言え、リソースが十分なプロジェクトなどほとんど無いと言えるので、多くの場合に当てはまるでしょう。

互換は壊すな！…なるべく

そもそも互換は壊すなよ、と言う話。互換は壊さないほうがいい。これに異を唱える人はいないでしょう。

「互換を壊したらメジャーバージョンを上げればいい」ではなくて「絶対に壊さない」くらいの意識でAPI設計をする。それくらい慎重に設計したとしても互換を壊さないといけない日は往々にしてやってくる。

非互換修正は自分に跳ね返ってくる

そもそも、互換を壊すことはユーザーを失うことです。非互換修正に追随するコストをユーザーに払わせる以上のメリットをユーザーに示せるかどうかという当然のトレードオフ以前に、これまでせっかく積み上げてきた既存ユーザーの一部を間違いなく失うという事実は受け止めなければならない。

メジャーなソフトウェアであればいざしらず、システムの片隅で使われるようなソフトウェア、つまり僕たちが作っているようなソフトウェアに非互換修正が入り、システム全体が動かなくなるとしたらたまったものではないでしょう。

それが、数少ないユーザーの全てを失う要因になるかもしれません。だからこそ、非互換修正をしないように注意を払う必要がある。これはソフトウェアとしての協調性の話でもあります。

もちろん、自分以外誰も使っていないようなソフトウェアであればその限りではありません。

それでも互換は壊れる

もちろん人間は間違えるのでイケてないインターフェースを作ってしまうことは避けられません。また、過去には良いとされていたインターフェースも、時代が変わってイマイチになることもなる。それに、人間が進化してより良いインターフェースを発明することもあります。

脱線しますが、そもそもインターフェース設計は難しいものです。semver的には、バージョン0の間は互換を壊してもいいことになっているので、そこで実際にユーザーに利用してもらい、トライアンドエラーを繰り返しながらインターフェースを固めていくのは良いやり方です。

話を戻すと、いくら初期設計時に慎重を期したとしても後方互換を壊したくなることはあります。とは言え、本当に壊す時にはそれ以上に慎重になるべきです。新インターフェースのほうが今より間違いなく良いという確信を持ってから互換を壊すべきです。

「新インターフェースのほうが今より間違いなく良いという確信」とはつまり、現行バージョンを使い続けるユーザーを最終的には切り捨てる覚悟をするということです。「新インターフェースのほうが間違いなく良いから、全員移行すべき」だと考える必要がある。新旧インターフェースどっちでも良いのであれば、混乱を招くだけなので、非互換修正すべきではないでしょう。

その際、移行パスを含めて事前アナウンスをしっかりやることが理想です。semver的にはメジャーバージョンを上げることになるでしょう。

複数バージョンをメンテしようなどとはゆめゆめ思うべからず

「メジャーバージョンを上げたとしても、旧バージョンもちゃんとメンテすればいい」という意見もあるかも知れませんが、それはほとんどの場合非現実的な理想論で、やるべきでもないと考えます。気軽に非互換変更をしてメジャーバージョンを上げ、逆にここを真面目に考えすぎて消耗してしまうケースが結構あると感じたことがこのエントリを書くモチベーションになっています。

ソフトウェア開発における再優先事項はメインラインに手を入れ続けることであり、旧バージョンのメンテナンスに労力を費やすことは、よほどリソースに余裕が無い限りは意味がありません。意味がないどころか、メンテナのモチベーションに逆効果になることも多いでしょう。

もちろん移行猶予期間として、一定の間、旧バージョンのメンテナンス期間を設けることは誠実ですし、ユーザーが減ることも防ぐでしょう。リソースに余裕があればやれるに越したことはありませんが、余裕があればの話です。旧バージョンのメンテナンスという、あまりモチベーションが上がらなさそうなタスクをやりたい人がいるかどうかも大事な観点です。

それ以外の理由で旧バージョンのメンテを期限を設けず継続することは無駄だと考えます。旧バージョンにも使い続けられる良さがあるのであれば、新バージョンは名前を変えるなどして、別ソフトウェアとしてプロジェクトを分けてしまった方が良いでしょう。

結果として古い方のソフトウェアのメンテナンスは滞るかも知れません。それでも使い続けたい人がいるのであれば、その誰かにメンテナンスを引き継いでしまうこともできます。そっちの方が、旧バージョンのメンテナンスを押し付けられることより、モチベーション高く引き受けてもらえるのではないでしょうか。

まとめ

話が戻ってきますが、結局の所、非互換修正は作者側も大きな痛みを伴う決断です。それらを踏まえて、非互換修正を入れるかどうかの判断をするべきでしょう。

セマンティックバージョニングに対しても思うところがあるのでなにか書こうと思ってましたが、今回はここまで。とは言え誤解を生まないように書いておくと、semver自体は悪いものだとは決して思っていません。