バージョンアップの採番方法について

質問

最初の正式リリースが1.0.0だったとして、
バージョンアップするときの採番基準はどのように考えればよいのでしょうか？

最初は、

1.0.0→1.0.1　小規模バージョンアップ
1.0.0→1.1.0　中規模バージョンアップ
1.0.0→2.0.0　大規模バージョンアップ

だと思ったのですが、何をもって小（中・大）規模とするのか？が
思いつきませんでした。

例えばドキュメントやソースコードのバージョン管理の場合の基準を教えていただければ幸いです。

回答No.3

kalze · ベストアンサー

３つの組み合わせの場合ですね？
４つの場合もあるので、一応確認

メジャーバージョン.マイナーバージョン.リビジョン

以下それぞれが変わるとどうなるか。
・メジャーバージョン
根本的に変更している場合に変更される
基本から作り直したり、設計思想を変更したり、根源を揺るがす変更があった場合

・マイナーバージョン
仕様変更を伴う修正・変更・追加。
大基は変わっていませんが、インターフェースに違いがでたり、機能が追加されたりなど

・リビジョン
仕様変更を伴わない、修正など

４つのブロックの場合は、最後にビルドがつくことがあります。

以上が最も一般的なつけ方ですね

お礼

３つで問題ありません。3番目はリビジョンというのですね。初めて知りました。
ドキュメントの場合は、以下のような感じでしょうか。

・メジャーバージョン
章構成の大幅変更、文体の大幅変更等、ページ構成の大幅変更（デザイン）

・マイナーバージョン
章の追加

・リビジョン
ページの追加、情報修正、誤字脱字修正

とても参考になりました。
ご回答ありがとうございました。

回答No.5

noname#223623

機能が変われば大規模バージョンアップとするけど。あとは個人の感覚。会社だとルールを作ってればいいんじゃないだろうか。個人的には致命的なバグは中規模、そうでないバグは小規模とかやるけどそれほど厳密ではないです。

余談だけど、昔ACCESS95が出たときバージョンが2から7(だったかな)に上がった(ExcelだかWordにあわせたらしい)。

お礼

バージョンがばらばらだと少し気持ちが悪いですよね。
大きな節目のときは思い切ってメジャーバージョンアップすることも検討してみます。
ご回答ありがとうございました。

回答No.4

matyrcry

制御器のＲＯＭですが、うちの場合は
臨時のバグ修正すると小位を上げる。
次回のロット切り替えで製造部門にＲＯＭ配布するので中位を上げる。
ハード変更などで大規模な機能変更が起きたら大位を上げる。
こんな感じです。

お礼

ハードの場合は型番≒バージョンなのかな？と思っていましたが
しっかりバージョン管理しているのですね。
ご回答ありがとうございました。

回答No.2

日吉 龍（@VDSL）

私の経験では、

小規模バージョンアップ...バグフィックス
中規模バージョンアップ...(少数の)機能追加
大規模バージョンアップ...動作/開発プラットフォームの移行、大規模機能追加など

といったところでしょうか。

あとは、自分で修正している間は1.0.xにしておいて、公開時に1.1.0にするという手もあると思います。

お礼

小規模＝バグフィックスなら99を超えるかもしれませんね（笑）
だいたい私の感覚と一緒でした。
非公開のときは1.0.0.xでバージョン付けをするかもしれません。
ご回答ありがとうございました。

回答No.1

beam-

Myルールでいいですよ。

WinとかMacなんてサービスパックやマイナーアップと言いながら中身総入れ換えになってるなんてザラですからね。

自分で判ればＯＫです。

お礼

自分も履歴管理くらいで考えてましたが、
他人に聞かれた時困ると思いまして。
ご回答ありがとうございました。