どうも、バンクーバーでぶらぶらしている@t32kです。最近は暇なのでもっぱらOSS活動に勤しんでおります。そんなわけで日々のアプリケーション開発において重要になってくるのがバージョニングです。
今日はセマンティック バージョニングについて解説します。自身が公開しているライブラリやパッケージのコードを何かしら修正したら、それに伴いバージョンを上げるのが一般的だと思うのですが、実はどのようにバージョンを上げるのが適切なのか、昔の私は理解していませんでした。
『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』などと、なんとなくにバージョニングをしていました。
t32k、怒られる！
If the plugin’s API changes dramatically (for example, when sortOrder option is renamed to config), there should be a major version update. See http://semver.org.
そんなときに起こったのが上記の事件です。grunt-csscombという私が管理しているGruntプラグインですが、そのアップデートの際に私がバージョニングを間違えてしまい、同じCSSCombチームのロシアのサンクトペテルブルク在住の青年エンジニアに怒られている悲惨な状況です。
彼の言い分は、「APIを変更したので、この場合はSemantic Versioningのルールに従ってメジャーバージョンを上げるべきであり、そうすることでユーザーも予測・対応しやすい」とのことです。
恥ずかしながら、この時初めてSemantic Versioningなるものを知りました。それよりも30歳も過ぎた大人がですね、地球の裏側ほど離れている、見たこともない青年に怒られている事実に私はへこみましたorz…
セマンティック バージョニングの翻訳
ということで、そのSemantic Versioningなるものを勉強してみました。
Semantic VersioningはGravatarsの考案者であり、GitHubの共同創設者でもあるTom Preston-Werner氏によって作成されました。去年、Rubyのバージョニングにも導入されて話題になってましたね。
勉強がてら翻訳して、先日プルリクエストがマージされましたので、現在日本語でも閲覧可能です。
2度とですね、僕みたいな悲しいおっさんを増やしたくないので、皆さんもちゃんと読んでOSS活動しましょう。
セマンティック バージョニングの導入
詳細は公式サイトを見てもらえればよいのですが、なにせ長いですので、ざっくり、最低限、以下のことだけ覚えてください。
- APIの変更に互換性のない場合は、メジャーバージョン上げる
- 後方互換性があり機能性を追加した場合は、マイナーバージョンを上げる
- 後方互換性を伴うバグ修正をした場合は、パッチバージョンを上げる
例えばVersion 3.2.1の場合、メジャーバージョンは3、マイナーバージョンは2、パッチバージョンは1ということになります。
一番重要なのはAPIに変更があった場合、メジャーバージョンを変更しなければならないということです。先のgrunt-csscombの件もsortOrderというオプション名をconfigに変更したので、このプラグインを使用しているユーザーはGruntfileを更新しなければならないケースが出てきます。
逆を言えば、セマンティック バージョニングが浸透しているコンテキストにおいては、メジャーバージョンのアップデートだけ気にしていれば、ユーザーは気軽に自身の依存しているパッケージをアップデートできるということです。
複雑なアプリケーションになればなるほど、依存するパッケージも多くなるので、それらをアップデートする際にちゃんと動作するのか、ひとつひとつ気に病むのは大変ですよね。セマンティック バージョニングという共通ルールは、そういった問題を解決するためにあります。
以前までのバージョンに対する私の一般的な印象は、大きければ大きいほど安定しているといったものでした。実際、そういった意味で商業的なバージョニングもあります（大した機能追加もないのに、大げさなバージョン名をつけるなど）。
例えば、Google Chromeは2014年12月現在バージョン39ですが、これはセマンティック バージョニングの観点から言えば、バージョン1.0でパブリックなAPIが定まってから38回もAPIが変更されたということになります（実際は高速リリースサイクルのためですが…）。
そのため、セマンティック バージョニングにとってメジャーバージョンが大きいということは開発者にとっては、APIがコロコロ変わるということであまり好ましくない状況といえるかもしれません。
しかし、気軽に作成・公開したパッケージで、『やっぱりこのメソッド名イケてないわー変えたいわー』といような状況が考えられます。そのような場合、新旧のAPIを両方残し、旧APIをdeprecatedと宣言して、マイナーバージョンを上げるだけに留めたほうがよいでしょう。
実際、私の作っているCSSの指標を計測するパッケージStyleStatsも、比較的軽微なAPIの変更を3回もしたため、あっという間にバージョンが4になってしまった経験があります。その都度、APIの変更がどういったものなのかユーザーに確認させるのは良くないことです。
そうゆうわけで、まとめますと、
- セマンティック バージョニングを守ろう
- リリースノートをちゃんと書こう
です。ありがとございました。
合わせて読みたい
