いいですよね、リリース。(雑な導入)GUIアプリケーション(Webアプリやモバイルアプリ)のバージョン番号をどうやって決めるか(バージョニング)を迷ってしまったので、考えていることを一度吐き出してみることにしました。結論からいうと、GUIアプリケーションのバージョニングはSemVerにこだわる必要はないです。サービスを提供する主体として、開発するチームとして、そのバージョン表記によって誰に何を伝えたいのかがハッキリしていて、それが伝えたい人々に伝われば、何だっていいです。SemVer現代のWeb界隈でデファクトスタンダードなバージョン記法といえば、セマンティックバージョニング(通称SemVer)ですよね。2.25.3)のような、ドットで区切られた3つの数値によって表現する方法です。それぞれの桁のバージョンアップは、次のような意味を持ちます。(パッチバージョン)の数字を上げるのは、外部とのAPIを変えずに(後方互換を保ったままに)不具合を修正した場合です。旧バージョンの間違った振る舞いを正しくするために使います。(マイナーバージョン)の数字を上げるのは、従来のAPIの後方互換を保ったままに外部とのAPIを追加した場合です。(メジャーバージョン)の数字を上げるのは、従来のAPIと後方互換がない(互換性が破壊された)変更がある場合です。細かいところは前述の原典のサイトを見ていただいたほうがいいのですが、私はざっくりとこのように理解しています、ということで。SemVerは、ライブラリの利用者がライブラリのバージョン表記を見て、自分のプロダクトに更新を取り込むべきかどうかを判断する際に、よい指針となります。ライブラリの作者と利用者にとって、素晴らしいコミュニケーションツールです。言い出しっぺのNPMでは遵守されていますし、他のパッケージ管理ツールも緩やかに似たようなルールを取り込んでいっている気がします*1。GUIアプリケーションとSemVerさて、これをGUIアプリケーションのバージョンに適用するとどうなるでしょうか。実際にストアを見てみると、SemVer的なバージョニングを実施しているプロダクトは少なくないように思えます。私も会社で作っているAndroidアプリやiOSアプリやWebアプリに、SemVer準拠なバージョンを与えることが多いです。SemVerなアプリが多いSemVerはライブラリ/パッケージのために生まれました。GUIアプリケーションにとっても適したバージョニングなのでしょうか。前述した、それぞれの桁の意味について、GUIでの在り方を再考してみましょう。数字を上げるのは、ユーザーからの見た目や使いかたを変えずに、間違った挙動を正しくするためです。数字を上げるのは、従来の使い勝手を崩さずに、機能を追加した場合です。数字を上げるのは、従来の使い方ができない部分が出てくるくらいにUIの更新があった場合です。こんなところでどうでしょうか。SemVerでいうAPIを「ユーザーの使い勝手」という定性的なものに置き換えた形になります。数字を上げるのは、ユーザーからの見た目や使いかたを変えずに、間違った挙動を正しくするためです。これは問題なさそうです。UIを変えずに内部処理の修正だけをしていた場合や、レイアウト崩れを修正した場合などに適用できそうです。数字を上げるのは、従来の使い勝手を崩さずに、機能を追加した場合です。......ちょっと苦しくなってきました。どのくらいまでならUIを変えても「従来の使い勝手が崩れていない」と判断できるのでしょうか。機能要件は変わってないしコンポーネントの配置もほとんど変わっていないけれど、カラーリングやアイコンのリニューアルを行ったら、それは「従来の使い勝手が崩れていない」のでしょうか。数字を上げるのは、従来の使い方ができない部分が出てくるくらいにUIの更新があった場合です。意味合いも強かったv1」や「v1をもっとちゃんとしたやつ版のv2」を作った後、v3にするタイミングを逸しているところとか、あるんじゃないでしょうか*2。えいや!」と上げてるのでしょうか。うちはこうしてるぜ!的なのがあれば、Qiitaとかブログに思想をつらつらと書いて教えていただけるとめちゃくちゃ助かります。SemVerではない運用SemVerではないバージョン記法を採用しているプロダクトもあります。バージョン記法を採用しています。Xが上がったときは実際にそこそこびっくりする程度にUIが変わった気がするので、おそらくこれはメジャーバージョンとして運用されているのでしょう。Yは機能追加や不具合修正の両方でカジュアルに上げているのだと思われます。ChromeはMAJOR.MINOR.BUILD.PATCHChromeは数値が4つ並んでいます。Chromeとしてのバージョニングのルールは見つかりませんでしたが、Chromiumプロジェクトにそれっぽい記載がありました。www.chromium.orgBUILDやPATCHはRC版のリリースを重ねるために用意されているようです。MAJORとMINORはChromeとしてリリースされるようなちゃんとしたバージョン付けに利用されるとのこと。MAJORはやはり、後方非互換の変更を表すために利用されるようです。