メジャー/マイナー/パッチのバージョン番号はいつ変更しますか？
重複の可能性：
どの「バージョン命名規則」を使用していますか？
リリースの直前または直後にメジャー/マイナー/パッチのバージョン番号を変更しますか？
例：あなたは1.0.0を世界にリリースしました（huzzah！）。しかし、待って、あまり祝わないでください。 1.1.0が6週間でリリースされます！したがって、バグを修正して新しいビルドを行います。 そのビルドは何と呼ばれますか？1.1.0.0または1.0.0.xxxy（xxxyは1.0.0のビルド番号の増分です）？
1.1.0には100の機能とバグがある可能性があることに注意してください。したがって、1.1.0に近いところはないため、1.0.0.xxxyと呼ぶのがよいでしょう。しかし、その一方で、別の開発者が2.0.0で作業している可能性があります。その場合、ビルドの名前は、それぞれ1.0.0.xxxyおよび1.0.0.xxxzではなく、1.1.0.0および2.0.0.0の方が適切です。
ソフトウェアをリリースしたら、バージョン番号をすぐに増やします。
どうして？
Semantic Versioning のようなスキームに従っていて、バージョンにビルド番号があると仮定します。したがって、[メジャー]。[マイナー]。[パッチ]。[ビルド]のようになります。 [メジャー]。[マイナー]。[パッチ]の部分をバージョンと呼びます。
開発中に複数のビルドを作成します。各ビルドは、次のリリースの開発スナップショットです。開発ビルドとリリースビルドに同じバージョンを使用することは理にかなっています。バージョンは、作業中のリリースに向かってを示します。
リリースの準備をしていて、ソフトウェアがすべてのテストに合格した場合、バージョンを更新しなければならなかったからといって、ソフトウェアを再構築して再テストする必要はありません。最終的にリリースするとき、「ビルド1.1.0.23」は今後「バージョン1.1.0」と呼ばれることになります。
リリース後の増分モデルは、ブランチングにも意味があります。メインライン開発ブランチがあり、リリースのメンテナンスブランチを作成するとします。リリースブランチを作成すると、開発ブランチはそのリリースのバージョン番号にリンクされなくなります。開発ブランチには、次のリリースの一部であるコードが含まれているため、バージョンにはそれが反映されているはずです。
私は通常、内部バージョン番号にSemVerを使用しようとします。バージョン番号のセマンティクスに基づいてリリースについて何かを知ることができるのは素晴らしいことです。
開発中、バージョン番号をすぐに変更しようとします（可能な場合）。変更が重大な変更であるかどうか（バージョン番号に影響を与えるかどうか）を判断することが難しい場合があるため、何も「確定」されていません。
特定の例に対処するには：
- 開発中、プレリリースバージョンは1.0.1-alpha.1、1.0.1-alpha.2などになります。
- バグ修正の最終リリースはバージョン1.0.1になります。
そうは言っても、「公開されている」製品のバージョン番号は、マーケティングによって設定されることが多く、完全に異なります。これは私の手に負えないので、心配する必要はありません。
答えの中にA.B.C.Dがあるとしましょう。いつ各コンポーネントを増やしますか？
基本的には会社の方針によって決まります。当社のポリシーは次のとおりです。
- A-重要な（> 25％）機能またはインターフェースの変更または追加。
- B-機能またはインターフェースの小さな変更または追加。
- C-インターフェイスを壊すマイナーな変更。
- D-インターフェイスを変更しないビルドの修正。
大規模なプロジェクト/組織では、メジャーバージョン番号とマイナーバージョン番号はマーケティング部門によって制御され、通常はマーケティング上の理由から増分されます。私の組織では、グループは毎年1つのメジャーリリースと1つのマイナーリリースをリリースすることを目指しています。メジャーリリースには重要な新機能が含まれており、同じメジャーバージョン番号を持つすべてのリリースのAPI間にバイナリ互換性があることが期待されています。ただし、たとえば、約束された機能が提供されない、またはその逆がカエルの競争を跳躍させると見られているため、メジャーバージョンの変更をマイナーにダウングレードすることをマーケティングが選択する場合があります。
メジャーおよびマイナービルド番号（a.b.c.dのcおよびd）は通常、開発によって制御されます。 cはビルド番号で、dはcの特定のリリースまたはバージョンのパッチに使用されます。
あなたの場合、メジャーバージョン番号とマイナーバージョン番号を変更しても、メジャービルド番号とマイナービルド番号が正確であることを確認するよりも重要ではありません。私の組織では、ソース管理の分岐プロセスの一環として、メジャーとマイナーのビルド番号を変更しています。メインブランチには通常、最新バージョンが含まれていますが、マーケティングがリリースのバージョン番号をまだ決定していない場合があります。
Eclipseの例 を試し、それに従います。説明よりは説明が得意ですが、効果的には次のように機能します。
1.0.0.0をリリースするとき、変更するバージョン番号は、行う変更のタイプによって異なります。
- APIに影響を与えないリリース。現在のAPIを期待どおりに機能させる舞台裏のバグ修正を検討してください。リリースは1.0.1です。
- APIを追加するが既存のAPIを変更しないリリースの場合、現在のクライアントを新しいバージョンと比較できないようにする新しい機能を追加した可能性があります。これには、上記の修正をいくつでも含めることができます。
- リリースは、現在のAPIを破壊し、何かを削除し、現在のクライアントとの互換性を損なう方法で何かを変更します。これには、上記の修正も含まれます。
バージョン番号の4番目のセクションの使用方法については、これを使用してNuget（.netで使用するパッケージ管理ソリューション）のさまざまなビルドを区別します。これにより、リリースされていないソフトウェアを更新する必要があるたびにキャッシュをクリアする必要がなくなります。
ソフトウェアを販売している場合は、販売/マーケティングでより大きなボーナスを獲得する必要があるたびに、新しいメジャーリリースが作成されます:-)。
あなたが何らかのコントロールを持っているなら：
メジャーリリース：
Python 2からPython 3.への変換など、以前のリリースとの非互換性があります。
新しい機能のチャンク全体があります。
機能の小さな変更に対するマイナーリリース。
- バグ修正のためのパッチリリース。
次のビルドはありません。その枝に。
私たちのスキームの理想化されたバージョン。
ブランチのバージョンIDはPRETTY_BRANCH_NAME-buildであり、PRETTY_BRANCH_NAMEはブランチの作成時に修正されます。
私たちの分岐スキーム（*）は次のとおりです：
トップレベルのブランチ、それぞれのPRETTY_BRANCH_NAMEはコード名です。そのレベルのバージョン番号といえば無意味です。計画的なスキームがあるかもしれませんが、リリース前に変更されます。
長期的な開発が行われるTNG（次世代）ブランチ。多くの場合、それさえ持っておらず、サブブランチを（リリースする）ことはありません。
現在の開発が行われるTCG（現在の世代）ブランチ。 PRETTY_BRANCH_NAMEはコード名です。
tPG（前世代）ブランチ。多くの場合、ここではこれ以上の開発は行われませんが、サブブランチで活動が行われる可能性があります。
メジャーリリースのベータ版が開始されると、サブブランチは（TPGの移行が遅い場合はTCGの）トップレベルのブランチで構成されます。 PRETTY_BRANCH_NAMEは「1.3.X」のようなものです（Xは数字ではなく文字です。つまり、ここから1.3リリースを提供する予定です）。ベータ版からのフィードバックは、次のメジャーリリースの作業が行われている間、ここで考慮されます。 TCGブランチ。
理想的には、リリースはそのブランチのスナップショットである必要がありますが、私たちは完璧ではないことがわかっており、他の人が次のマイナーリリースに向けて作業を続行できるように、最後の変更を行う必要があることがよくあります。したがって、サブブランチは最終的な安定化のために作成され、「1.3.X」ブランチの「1.3」、「1.3.1」のように、かなりの名前が公式バージョン番号になります（その時点ではマーケティングでも変更したくない）。それぞれの最後のビルドはリリースです。
4番目のレベルがある場合、サブブランチの名前は「1.3.0.X」で、サブブランチ3は「1.3.0.0」「1.3.0.1」でした。
（*）リリースレベル。これらのそれぞれにプロジェクトのサブブランチがある場合があります。