内部リリースにバージョン番号を割り当てる必要がありますか？
私たちの環境では：
- 内部リリースは、テストプロセスを経たものです。ビルドは成功または失敗します。
- 外部リリースは、ユーザーに配信されるリリースです。
外部リリースの場合、バージョン番号が確実に表示されます。しかし、内部リリースにはバージョン番号を割り当てる必要がありますか？
私の職場では、ビルドごとにビルド番号をスタンプしています。ビルド番号は1から始まり、単調に増加しています。したがって、ビルドシステムによってビルドされたすべての内部ビルドは、新しいビルド番号を取得します。バージョンは最終的にx.y.z（ビルド）として記述され、x.y.zは最終的にリリースされるバージョンです（5.2.8など）。これは実行可能ファイルにも書き込まれるため、実行されているバージョンを確認できます。お客様にリリースされない場合でも、製品のすべてのビルドのコピーを保持し、ビルドをソース管理のコミットリビジョンに関連付ける方法があります。
常識
バージョン番号付けの目的は、任意のバージョンに対応する正確なコードを見つけることを目的として、さまざまなリリースを識別することです。
原則として、以下に関心があります。
- どこかでまだ使用されている可能性のあるバージョン（ソフトウェアは社外または会社内の別の部門に送信されたため、製品開発チームの管理下にありません）。
- 正常に機能するバージョンなので、一部の変更によって本当に問題が発生する場合は、最後の信頼できるバージョンに戻って、必要に応じて出荷できます。
したがって、バージョンが成功したテストプロセスに合格した場合は、2番目のケースになります。したがって、バージョン番号は、それが内部リリースである場合には意味があります。
より正式なアプローチ
Semantic Versioning を適用した場合でも、バージョン管理の基準はリリースのままです。
- バージョン管理されたパッケージがリリースされたら、そのバージョンの内容を変更してはなりません。変更はすべて新しいバージョンとしてリリースする必要があります。
内部リリースか外部リリースかは明示されていませんが、両方を想定する必要があります。開発バージョンは原則として外部リリースではないため：
- メジャーバージョンゼロ（0.y.z）は初期開発用です。いつでも何でも変わるかもしれません。パブリックAPIは安定していると見なすべきではありません。
現在、SemVer標準では、プレリリースの番号付け方式にある程度の自由を認めています。
- プレリリースバージョンは、パッチバージョンの直後にハイフンとドットで区切られた一連の識別子を追加することによって示すことができます。
また、複数の異なるビルド間で1つのバージョン番号を共有することもできます。
- ビルドメタデータは、パッチまたはプレリリースバージョンの直後に、プラス記号と一連のドットで区切られた識別子を追加することによって示すことができます。
したがって、ここでの問題は、内部リリースと外部リリースを区別するものではなく、ビルドとリリースを区別するものです。
最後に、以前と同じ結論：成功したテストプロセスに成功したバージョンは、明確に識別されるに値します。ソース管理システムでビルド番号を追跡したくない場合は、適切なバージョン番号を使用する必要があります。