複製
こんにちは、
そこで最近、Groovyがバージョン1.6にリリースされたことを知り、Java Posse Podcast を聞いているときに、このリリースには2.0リリースであるべきだった多くの機能が詰め込まれているとコメントしていました。
それは私に考えさせました。バージョン番号は任意ですか? 意味があると思っていたのですが、そうではないようです。すべてマイルストーンベースで、プロジェクトごとに設定されているだけですか?
チームはバージョン番号とリリースをどのように管理していますか?
前もって感謝します
マーケティング用のバージョン管理と技術的な使用のためのバージョン管理を区別します。
マーケティングの場合、答えは「顧客に考えてもらいたいことは何でも」です。その場合、「主要な新しいバージョン」には、おそらく主要なバージョン番号が付随するはずです。
また、慎重な顧客は、時間が経過してテスト環境で試すまで、「主要な」新しいリリースを使用することを躊躇することに注意してください。「ビルド変更」リリースは、インストールに多くのプロセスを必要としないバグ修正やその他のマイナーなものが含まれていると認識されています。
技術的な用途については、「開発者向けにエンコードしたい情報は何でも」というのが答えです。これを行う正しい方法はありません。それはあなたの目標に依存します。
おそらく、「メジャー」バージョンは「多くの新しいバグを意味する可能性がある重要な変更」を意味します。おそらく、すべてのコンパイルで新しい「ビルド」番号が発生します。おそらく、日付ごとの毎晩のビルドタグがあなたのバージョンです。時間、スクラム サイクル、マイルストーン、機能などに基づいて作成できます。
それらは非常に恣意的です。多くの人が次のようなものを持っているのが好きです
[major].[minor].[release].[revision]
しかし、VP の 1 人が望んでいないという理由で、1.0 ブランドの製品のリリースを拒否した企業にも参加しました。マーケティングもこれに影響を与える可能性があります。
メジャー バージョンを増やすための良い質問は次のとおりです。
これが有料の製品である場合、顧客はこの新しいバージョンにアップグレードするためにお金を払いますか?
もしそうなら、メジャー番号を増やすと良いかもしれません。
MajorRelease.MinorRelease.Hotfix
バージョン番号は任意ですが、いくつかのルールがあります (私はそう思います)。非常にマイナーな変更またはバグ修正は、通常 0.0.1 ずつ増加します。つまり、V1 は V1.0.1 になります。機能に対するマイナーな変更は 0.1.0 増加します。つまり、V1.0.1 が V1.1.0 になります。大きな変更または書き直しは、1.0.0 の増加、つまり V2 になります。
とはいえ、多くの企業は、同様の変化が 0.1.0 のときに 1.0.0 ずつ上昇することで、顧客に何か大きな変化があることを納得させようとしているようです。また、サポート契約に依存している一部の企業は、0.1.0 のアップデートを無料で提供しますが、1.0.0 のアップデートは有料です。
また、IIRC では、一部のプロジェクトでは、奇数バージョンの実験的ビルドと偶数バージョンの安定ビルドを意味する傾向があります (したがって、V3 は危険であり、V4 は安定しています)。
ライブラリの場合、バージョン番号は2 つのリリース間の互換性のレベル、つまりアップグレードの難易度を示します。
バグ修正リリースでは、バイナリ、ソース、およびシリアライゼーションの互換性を維持する必要があります。
マイナー リリースはプロジェクトごとに意味が異なりますが、通常はソースの互換性を維持する必要はありません。
メジャー バージョン番号は、3 つの形式すべてを壊す可能性があります。
根拠についてはこちらに詳しく書いています。