バージョンの付け方を調べてみた

 2019-11-25 |  2020-5-14 |  4 min read


この記事は、1年間更新されておりません。

はじめに

今日、別部門の先輩から
「お前のところのプロジェクトはどんな感じでバージョンの番号つけてる?」
と聞かれたので、
「年月日で付けてます。」
と返したのですが、世間ではどういった感じで付けてるかをしっかりと意識してみたことはないと思い、調べてみました。

さまざまな命名方法

いくつか、慣習で決められているものもあるようです。
丸投げになってしまいますが、めちゃくちゃまとめられた記事を見つけたのでこちらを見るとわかりやすいです。

バージョンにあれこれ考えを巡らせてみる

各ソフトウェアのバージョン定義

自分が思いついた物のバージョン表記について調査しました。
LTS 版や Stable 版などの表記は省いてます。

OS

  • Ubuntu
    • [YY].[0M]
    • YY: 年
    • 0M: 月
  • ArchLinux
    • [YYYY].[0M].[0D]
    • YYYY: 年
    • 0M: 月
    • 0D: 日
  • CentOS
    • [A].[B].[CCCC]
    • 恐らく
      • A: Major
      • B: Minor
      • C: Patch
  • Windows 10
    • [AAAA]
    • A: Version

プログラミング言語

  • Python
    • [A].[B].[CC]
    • A: Major:重要な変更リリース
    • B: Minor:大きくない変更
    • C: Micro:バグフィックス
  • Node.js
    • [AA].[BB].[C]
    • A: Major
    • B: Minor
    • C: Revision
  • Ruby
    • [A].[B].[C]
    • A: Major:メインのバージョンアップ
    • B: Minor:互換性があるバージョンアップ
    • C: Patch:バグフィックス
  • Java
    • [AA].[B].[C].[D]
      • A: Feature: 機能リリース
      • B: Interim: 暫定リリース(バグ修正、機能強化)
      • C: Update: セキュリティリリース、リグレッション解決、バグ修正などのアップデート用
      • D: Patch: 重大な問題を修正するための緊急リリース
        • Patch は 0 の場合無視される

アプリ

  • Unity
    • [YYYY].[A].[BB]
    • Y: 年
    • A: Major
    • B: Minor
    • Major が 4 だと、LTS 版らしい
  • IntelliJ
    • [YYYY].[A].[B]
    • Y: 年
    • A: Major
    • B: Minor
  • Chrome
    • [AA].[B].[CCCC].[DD]
    • A: Major
    • B: Minor
    • C: Build
    • D: Patch
  • Docker
    • [AA].[BB].[C]
    • A: Major
    • B: Minor
    • C: Patch
  • HearthStone(Game)
    • [AA].[B].[C].[DDDDD]
    • A: Major
    • B: Minor
    • C: Patch
    • D: Build?(想定)

調べてみて

  • バージョンは、ユーザ側で改修させることを想定していないのであれば、ただの符号です
  • 定期リリースやリリースの重要度が固定されているもの、符号として扱うことでユーザにわかりやすくるすことを想定するなら、バージョンを日付にするのはありよりのあり
  • 何回か命名規則を変えているものや、ややこしい単語を追加しているものはそれだけで、ユーザ側は理解しづらくなるし萎えます
  • バージョンは正しく管理できていれば何でも良さそう
  • 正しく定義されていると、共通認識ができるので運用しやすそうとも思いました

さいごに

色々なバージョンの付け方があって、面白かったです。 複雑なバージョンをつけるのは、それはそれでロマンがありますが、やはり使用者にとってわかりやすくするのが一番だと思いました。

セマンティックバージョニングでも、同じようなことが書かれています。

このアイデアは新しいものでもなければ、革新的なものでもありません。実際、みなさんも似たような取り組みを既におこなっているかもしれません。問題は「似ている」のでは不十分だということです。正式な仕様書による取り決めがなければ、バージョンナンバーは依存性の管理において基本的には無意味です。上記のアイデアに対して名前と正確な定義を与えることよって、あなたの開発するソフトウェアにおいて、あなたの意図がユーザーに対して伝わりやすくなることでしょう。一度、これらの意図を正確にしてしまえば、柔軟な(しかし、柔軟すぎてはいけない)依存性の仕様を作ることができます。 セマンティック バージョニング 2.0.0

決して Stains;Gate のダルみたいな命名はしてはいけない (確かにかっこよくてロマンはあるけど)

バージョンを名前で管理するときは、最初にちゃんと決めよう。

後もっとわかりやすいところに定義を書いとけ!!めちゃくちゃ探したぞ!

参考

各種ソフト・ハード


このエントリーをはてなブックマークに追加

comments powered by Disqus