2022年5月1日日曜日

ソフトウェアのバージョン番号について

 ソフトウェアのバージョン番号ってみんな好き勝手につけるじゃないですか。

番号のつけ方にどういうものがあったっけーとふと思って、有名なやつをちょっと調べてみました。新しいネタやためになりそうな考察は特に何もありません。

セマンティックバージョニング

多分一番一般的なやつ。 "1.2.3"みたいにメジャーバージョン、マイナーバージョン、パッチバージョンの3つの数値をピリオドで区切って、以下のような規則で数値を変更します。

  • メジャーバージョンの変更(例: 1.2.3 → 2.0.0): 後方互換性が失われる変更が加えられた(例: 1.2.3 → 2.0.0)
  • マイナーバージョンの変更(例: 1.2.3 → 1.3.0): 後方互換性が保たれる変更が加えられた、たとえば既存の仕様の影響がない新機能が追加されたなど
  • パッチバージョンの変更(例: 1.2.3 → 1.2.4): 仕様自体には変更がないがそれ以外の変更が加えられた、たとえば不具合修正やドキュメントが変更されたなど

互換性の有無が一目でわかるのでライブラリー向き。というかライブラリーはこんな感じでつけてくれないと怖くて使えません。value-schemaもこの方法を採用しています。

ソフトウェア開発者以外にとっては見慣れない表記なので、パッと見て小数と勘違いして「1.9.0のほうが1.10.0より新しい」と判断しちゃうかもしれません。

アプリケーション・ソフトウェアの場合は必ずしもこれに従う必要はありませんが、見た目とか操作感とかデータファイル形式が大きく変わったらメジャーバージョンを上げているところも多いかも。

年月

「いつリリースされたか」に主眼を置いてたバージョン表記方法。西暦2022年5月1日にリリースされたものなら2022.05.01とか20220501とか22.05みたいなやつです。年月はだいたいグレゴリオ暦なのでヨーロッパ文化が前提のバージョン番号ですね。まあ和暦とか旧暦で番号をつける人はいないと思いますが。。。

リリース日が明確だけど、互換性の情報は捨ててるのでライブラリーには向きません。フォントのようにとにかく最新のものを使っておけば問題ないようなソフトウェア向きです。

アプリケーション・ソフトウェアの場合は、セマンティックバージョニングの項目で書いたように操作感などの問題、あるいは新バージョンでは対応プラットフォームを切り捨てることもあるので、一概に最新を使えばいいとは言えないから微妙です。開発側からすると最新版を使ってほしいんですが。

またバージョン番号とはちょっと違いますが、アルファベット順のコードネームをつけているソフトウェアもありますね。なんというか、先のことを考えているんでしょうか。26個使い切ったらまたAに戻ったりわけわからんことになります。

おまえのことやぞUbuntu。

マイナーバージョンの偶数が安定版、奇数が開発版

最近あまり見なくなったけど、以前のLinuxカーネルが「2.4.Xが安定版、2.5.Xが開発版」みたいな感じでした。Linux界隈でそういう規則で番号つけてるソフトが他にもあった気がします。GNOMEも前はそうだったかな。

まあそういうやり方もあるよね、というくらいの感想で、今なら開発版は-alpha.Xとか-rc.Xみたいなサフィックスをつけるのが一般的っぽいので特にメリットとかも感じられません。

ラピッドリリース

「バージョン番号の付け方」に分類していいのかわかりませんが、ChromeとかFirefoxみたいにとにかくリリースサイクルを早めてメジャーバージョンをポコポコ上げていくやつ。

これ嫌い。

0 件のコメント:

コメントを投稿