メジャー/マイナー/パッチのバージョン番号はいつ変更しますか？

重複の可能性：
どの「バージョン命名規則」を使用していますか？

リリース直前またはリリース直後にメジャー/マイナー/パッチのバージョン番号を変更しますか？

例：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です。

とはいえ、「一般向け」の製品バージョン番号はマーケティングによって設定されることが多く、完全に異なっています。これは私の制御不能であるため、心配する必要はありません。

答えにABCDがあると仮定しましょう。各コンポーネントをいつ増やしますか？

基本的には会社の方針によって決まります。当社のポリシーは次のとおりです。

• A-機能またはインターフェースの大幅な（> 25％）変更または追加。
• B-機能またはインターフェースの小さな変更または追加。
• C-インターフェイスを壊す小さな変更。
• D-インターフェースを変更しないビルドの修正。

大規模なプロジェクト/組織では、メジャーバージョン番号とマイナーバージョン番号はマーケティング部門によって管理されており、通常はマーケティング上の理由により増加します。私の組織では、グループは毎年1つのメジャーリリースと1つのマイナーリリースをリリースすることを目指しています。メジャーリリースには重要な新機能が含まれ、同じメジャーバージョン番号を持つすべてのリリースのAPI間にバイナリ互換性があることが期待されます。ただし、マーケティングでは、たとえば、約束された機能が提供されないため、メジャーバージョンの変更をマイナーにダウングレードすることを選択できます。

メジャービルド番号とマイナービルド番号（abcdのcおよびd）は通常、開発によって制御されます。cはビルド番号で、dはcの特定のリリースまたはバージョンのパッチに使用されます。

あなたの場合、メジャーとマイナーのバージョン番号を変更することは、メジャーとマイナーのビルド番号が正確であることを確認するよりも重要ではありません。私の組織では、ソース管理の分岐プロセスの一環として、メジャービルド番号とマイナービルド番号を変更しています。通常、メインブランチには最新バージョンが含まれますが、マーケティングではリリースのバージョン番号がまだ決まっていない可能性があります。

Eclipseの例を試します。説明するのは私ができるよりも優れていますが、効果的には次のように機能します：

1.0.0.0をリリースするときに変更するバージョン番号は、行っている変更の種類によって異なります。

• APIに影響を与えないリリースは、現在のAPIが期待どおりに動作するようにする舞台裏のバグ修正を検討し、1.0.1でリリースされます。
• APIに追加されるが、既存のAPIを変更しないリリース。現在のクライアントを新しいバージョンと比較できないようにしない新しい機能を追加した可能性があります。これには、上記の修正をいくつでも含めることができます。
• リリースは現在のAPIを破壊し、何かを削除し、現在のクライアントとの比較可能性を破壊する方法で何かを変更します。これには、上記の修正のいずれかが含まれる場合があります。

バージョン番号の4番目のセクションの使用方法については、これを使用してNugetの異なるビルド（.netに使用するパッケージ管理ソリューション）を区別します。これにより、未リリースのソフトウェアを更新する必要があるたびにキャッシュをクリアする必要がなくなります。

次のビルドはありません。その枝に。

スキームの理想的なバージョン。

ブランチのバージョン識別は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」であり、そのうちサブサブブランチは「1.3.0.0」「1.3.0.1」でした。

（*）リリースレベル。これらのそれぞれにプロジェクトのサブブランチがある場合があります。

ソフトウェアを販売している場合、販売/マーケティングがより大きなボーナスを獲得する必要があるたびに、新しいメジャーリリースがあります:-)。

何らかの制御がある場合：

1. 次の場合のメジャーリリース：

   • Python 2からPython 3への変換などを必要とする以前のリリースとの非互換性があります。

   • 新しい機能が多数あります。

2. 機能の小さな変更に対するマイナーリリース。

3. バグ修正のためのパッチリリース。