MW211 EXIT

devlog
設計/バージョン表記法
2014年03月28日
以下の三つの階層でバージョンを管理するのが一般的である。
┌─────────────┬────────────────────────┐
│(1) メジャーバージョン    │大規模な仕様の変更によりバージョンアップ        │
├─────────────┼────────────────────────┤
│(2) マイナーバージョン    │中規模な仕様の変更によりバージョンアップ        │
│                          ├────────────────────────┤
├─────────────┤小規模な仕様の変更によりバージョンアップ        │
│(3) メンテナンスバージョン├────────────────────────┤
│                          │バグの修正によりバージョンアップ                │
└─────────────┴────────────────────────┘
表記方法としては以下がある

【ピリオド二つ版】例:Ver.1.2.3
  ・1の部分…メジャーバージョン
  ・2の部分…マイナーバージョン
  ・3の部分…メンテナンスバージョン

【ピリオド一つ版】例:Ver.1.02a
  ・1の部分…メジャーバージョン
  ・2の部分…マイナーバージョン
  ・aの部分…メンテナンスバージョン

・アルファ版の場合は、末尾に「A」をつけたりする(「Ver.1.2.3A」)。
  ベータ版は「B」(クローズドベータ版は「CB」、オープンベータ版は「OB」)、
  リリース候補版は「RC」をつけるようだ。
  第一期リリース候補版の場合は「RC1」、第二期は「RC2」のように、
  さらに末尾に数字が付く場合もある。

・場面によってはメンテナンスバージョンについては省略される場合もある。

・初回バージョンは「1.0」で、それよりも前のドラフト版は「0.1」などが使われる。

・キャッシュが保持されるJavaScript外部ファイルやCSS外部ファイルについては
  参照URLの末尾に「?1.0」などと敢えてバージョンを埋め込んだ
  GETパラメータを付加することにより、
  画面リロードによるキャッシュ放棄をせずとも、
  バージョンアップ後のソースを強制的に読み込ませる手法がある。
分類:設計