皆さん、リリースしてますか！ いいですよね、リリース。（雑な導入）
GUIアプリケーション（Webアプリやモバイルアプリ）のバージョン番号をどうやって決めるか（バージョニング）を迷ってしまったので、考えていることを一度吐き出してみることにしました。
結論
結論からいうと、GUIアプリケーションのバージョニングはSemVerにこだわる必要はないです。サービスを提供する主体として、開発するチームとして、そのバージョン表記によって誰に何を伝えたいのかがハッキリしていて、それが伝えたい人々に伝われば、何だっていいです。
SemVer
現代のWeb界隈でデファクトスタンダードなバージョン記法といえば、セマンティックバージョニング（通称SemVer）ですよね。
バージョンを X.Y.Z （ex. 2.25.3）のような、ドットで区切られた3つの数値によって表現する方法です。それぞれの桁のバージョンアップは、次のような意味を持ちます。
Z（パッチバージョン）の数字を上げるのは、外部とのAPIを変えずに（後方互換を保ったままに）不具合を修正した場合です。旧バージョンの間違った振る舞いを正しくするために使います。Y（マイナーバージョン）の数字を上げるのは、従来のAPIの後方互換を保ったままに外部とのAPIを追加した場合です。X（メジャーバージョン）の数字を上げるのは、従来のAPIと後方互換がない（互換性が破壊された）変更がある場合です。
細かいところは前述の原典のサイトを見ていただいたほうがいいのですが、私はざっくりとこのように理解しています、ということで。
SemVerは、ライブラリの利用者がライブラリのバージョン表記を見て、自分のプロダクトに更新を取り込むべきかどうかを判断する際に、よい指針となります。ライブラリの作者と利用者にとって、素晴らしいコミュニケーションツールです。言い出しっぺのNPMでは遵守されていますし、他のパッケージ管理ツールも緩やかに似たようなルールを取り込んでいっている気がします*1。
GUIアプリケーションとSemVer
さて、これをGUIアプリケーションのバージョンに適用するとどうなるでしょうか。実際にストアを見てみると、SemVer的なバージョニングを実施しているプロダクトは少なくないように思えます。私も会社で作っているAndroidアプリやiOSアプリやWebアプリに、SemVer準拠なバージョンを与えることが多いです。
SemVerはライブラリ/パッケージのために生まれました。では、GUIアプリケーションにとっても適したバージョニングなのでしょうか。前述した、それぞれの桁の意味について、GUIでの在り方を再考してみましょう。
Zの数字を上げるのは、ユーザーからの見た目や使いかたを変えずに、間違った挙動を正しくするためです。Yの数字を上げるのは、従来の使い勝手を崩さずに、機能を追加した場合です。Xの数字を上げるのは、従来の使い方ができない部分が出てくるくらいにUIの更新があった場合です。
こんなところでどうでしょうか。SemVerでいうAPIを「ユーザーの使い勝手」という定性的なものに置き換えた形になります。
Zの数字を上げるのは、ユーザーからの見た目や使いかたを変えずに、間違った挙動を正しくするためです。
これは問題なさそうです。UIを変えずに内部処理の修正だけをしていた場合や、レイアウト崩れを修正した場合などに適用できそうです。
Yの数字を上げるのは、従来の使い勝手を崩さずに、機能を追加した場合です。
……ちょっと苦しくなってきました。どのくらいまでならUIを変えても「従来の使い勝手が崩れていない」と判断できるのでしょうか。機能要件は変わってないしコンポーネントの配置もほとんど変わっていないけれど、カラーリングやアイコンのリニューアルを行ったら、それは「従来の使い勝手が崩れていない」のでしょうか。
Xの数字を上げるのは、従来の使い方ができない部分が出てくるくらいにUIの更新があった場合です。
これだと Yとの境目がわからない んですよね……従来のUIとの地続きと呼べる範囲ならYでよくて、そうでない場合がXなのかな……
しっかりYと差別化しようとすると、 驚き最小の原則に反するケースじゃないと上げられなさそう なんだけど、流石にそれはまずいんじゃないかな……
メジャーバージョン上げられない問題
SemVerを愚直にGUIアプリケーションに適用しようとすると、Xであるメジャーバージョンを上げるのは、めちゃくちゃ勇気のいる破壊的な変更であるような気がしてきました。
実際、「市場検証の意味合いも強かったv1」や「v1をもっとちゃんとしたやつ版のv2」を作った後、v3にするタイミングを逸しているところとか、あるんじゃないでしょうか*2。
やってるところは「これはマイナーバージョンアップ（Y）でもいいと思うんだけど、大きな変更だから、記念も込めてメジャーバージョン（X）あげちゃえ！ えいや！」と上げてるのでしょうか。うちはこうしてるぜ！的なのがあれば、Qiitaとかブログに思想をつらつらと書いて教えていただけるとめちゃくちゃ助かります。
SemVerではない運用
SemVerではないバージョン記法を採用しているプロダクトもあります。
Twitterは X.Y のバージョン記法を採用しています。Xが上がったときは実際にそこそこびっくりする程度にUIが変わった気がするので、おそらくこれはメジャーバージョンとして運用されているのでしょう。一方、Yは機能追加や不具合修正の両方でカジュアルに上げているのだと思われます。
Chromeは数値が4つ並んでいます。Chromeとしてのバージョニングのルールは見つかりませんでしたが、Chromiumプロジェクトにそれっぽい記載がありました。
BUILDやPATCHはRC版のリリースを重ねるために用意されているようです。そして、MAJORとMINORはChromeとしてリリースされるようなちゃんとしたバージョン付けに利用されるとのこと。MAJORはやはり、後方非互換の変更を表すために利用されるようです。 ドキュメント上は。
WikipediaにあるChromeのリリース履歴の読み方が間違っていなければ、 1.0以降から今日の73.0に至るまで、マイナーバージョンが運用された実績がv4.1.249の1回しかない ように見えます。機能追加しかないように見えるアップデートでもメジャーバージョンを上げ続けてここまで来ています。まあ、ChromeはGUIアプリケーションというよりは仮想マシンに近いですし、JavaScript処理系の細かいところまで見ていけば全てのメジャーバージョンアップがちゃんと後方互換のない変更なのかもしれませんが……
そんなわけで、Chromeは事実上、メジャーバージョンとマイナーバージョンを統合している（ように見える）運用をしています。
バージョニングは誰のために
そもそもバージョニングは誰のために行うのでしょうか。私は バージョン番号から何かを読み取りたい人 のためにバージョンを運用するべきだと思っています。ライブラリやパッケージの場合は、後方互換性の程度を利用者に読み取ってほしくて、X.Y.Zという3つの数字を運用する、SemVerが重宝されることになりました。
では、GUIアプリケーションのバージョンは誰に何を伝えたいのでしょうか。
Webアプリやストアアプリに関しては、エンドユーザーには基本的に最新版を使ってもらうことを想定していて、ユーザー側で昔のバージョンを細かく使い分けることもないので、サポートの面から考えても「最新なのか、そうでなければどのくらい古いか」だけがわかればよさそうです。数値がひとつだけあれば、バージョニングは事足りてしまうかもしれません。 Chrome 73 といった表記も、それに近い部分がありますね。
一方で、それを提供する会社の社内ではどうでしょうか。広報担当と一緒にリリース内容をどう宣伝するか考えるときに「新機能や機能改善を含むリリース」なのか「不具合修正のみのリリース」なのかがバージョンを見ただけでひと目でわかるのは、とても便利そうです。 FEATURE.PATCH のようなふたつの数値で表すことにして、前者と後者のどちらが上がったのかを見ることで、社内のコミュニケーションを円滑にするのは、良い方法かも知れません。
もし、ユーザーに一定以上の負担を強いるタイプの大幅なUIリニューアルを、それなりの頻度で行う社風があるのであれば、後方非互換性を表すメジャーバージョンの運用も、視野に入れてもいいのかもしれません。メジャーバージョンを上げるようなリニューアルをするたびにユーザーに怒られているTwitterを見ていると、それがいいことなのか、少し疑問ではありますが。
まとめ
バージョニングは、プロダクトの作り手と、プロダクトを利用したり運用したりする人々との、コミュニケーションツールです。伝えたいことが必要十分に伝わるならば、必ずしもSemVerにこだわる必要はないと、筆者は考えています*3。
プロダクトの特性や、開発組織の特性によって、どのようなバージョニングを採用するかは工夫してもよさそうです。皆さんの組織では、どんなバージョニングをしてみたいですか？
