DUPLICATEは、バージョン番号
こんにちは、
の決定だから私は最近、Javaのポッセを聴きながらGroovyのがバージョン1.6にリリースされたことを見ましたポッドキャストでは、このリリースにどのように多くのパックが入っていたのか、彼らはコメントしていました。2.0リリース。
それは私の考えを得た。バージョン番号は任意ですか？私は彼らが意味を持っていたと思っていたが、私はそうは思わない。それはすべてマイルストーンベースであり、プロジェクトに設定するプロジェクトですか？
あなたのチームはあなたのバージョン番号とリリースをどのように管理していますか？
ありがとうございます事前にありがとう
技術的な使用のためのマーケティングとバージョン管理を区別します。
のマーケティングでは、「あなたの顧客が思うものは何でも」。その場合、「メジャーな新しいバージョン」にはおそらくメジャーバージョン番号が付いているはずです。
また、慎重な顧客は、テスト環境で試してみるまで、「メジャー」な新しいリリースを使用するのをためらうことに注意してください。 "ビルド変更"のリリースは、インストールに多くのプロセスを必要としないバグ修正やその他の軽微なものがあると認識されています。
の技術的な回答については、「開発者向けにエンコードする情報は何でも」。これを行う正しい方法はありません。それはあなたの目標に依存します。
おそらく、「メジャー」バージョンは、「新しいバグがたくさんある可能性のある重要な変更」を意味すると思われます。おそらく、新しい "ビルド"数はすべての単一のコンパイルで発生します。おそらく夜間の日付によるビルドタグがあなたのバージョンです。あなたは、時間、スクラムサイクル、マイルストーン、機能、何でもそれをベースにすることができます！
MajorRelease.MinorRelease.Hotfix
バージョン番号はarbitaryですが、親指foは（と思う）、いくつかのルールがあります。非常にマイナーな変更やバグの修正は通常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のアップデートに対して料金を請求します。
また、いくつかのプロジェクトは、奇数バージョンと安定ビルドのテストビルドを意味する傾向があります（V3は危険なので、V4は安定しています）。
非常に恣意的です。多くの人々は、彼らのバージョン管理方式として
[major].[minor].[release].[revision]
のようなものを持っていると、私はまたのVPの一つはしたくなかったので、1.0ブランド製品をリリースすることを拒否した企業にしてきました。マーケティングもこれに影響を与えることができます。メジャーバージョンを上げるために依頼する
良い質問ができ：
これは有料の製品であれば、顧客はこの新しいバージョンにアップグレードして支払うことになりますか？
もしそうなら、メジャー番号を増やすのが良いかもしれません。
ライブラリの場合、バージョン番号は、の互換性のレベルについてと2つのリリースの間の互換性の程度を示しています。
バグ修正リリースでは、バイナリ、ソース、およびシリアライゼーションの互換性を維持する必要があります。
マイナーリリースとは異なるプロジェクトを意味しますが、通常はソースの互換性を維持する必要はありません。
メジャーバージョン番号は3つのフォームをすべて破損する可能性があります。
私は根拠について詳しく書いたhere。