弊社の状況は以下の通りですが、どのような状況でもこの問題が気になります。
私たちは4つのプロジェクトからなるフレームワークを持っています:
バージョンを必要とし、Bean と util のバージョンに依存するモジュールもあります。
最後に、コア プロジェクトの特定のバージョンと 1 つ以上のモジュールで構成される顧客プロジェクトがあります。
これらのプロジェクトをバージョン管理する標準的な方法はありますか?
リリースを QA に提出し、リリースのメンテナンス (リリース = タグと可能性のあるブランチ) を使用して進行中の開発を管理しようとすると、私には単純に思えますが、非常に複雑になっています。
私は次のようなものを好みます：
1.2.0 - メジャー バージョンとマイナー バージョン + リリース。
1.2.1 - 次のリリース
1.2.0_01 - 1.2.0 リリース (ブランチ) のバグ修正
等
何か案は？
major.minor.bugfix を使用します。メジャー リリースは、大きな変更の場合にのみ発生します。API の変更がある場合は、マイナー リリースが必要です。他のすべてのリリースはバグ修正リリースです。トラブルシューティング用にビルド番号またはリビジョン番号を記載しておくと便利ですが、非常に厳密な CM を使用している場合は、含める必要はないかもしれません。
これらすべてのプロジェクトのバージョン間の調整は、Apache Ivy や Maven などのツールの助けを借りて非常にうまく行うことができます。独自のバージョン番号を持つ 1 つのプロジェクトのビルドには、他のプロジェクト (の製品) の特定のバージョンの集約が含まれる可能性があるため、ビルド ファイルはボトムアップでバージョンの厳密なマッピングを提供します。[お気に入りのバージョン管理ツールをここに挿入] にすべて保存すると、素晴らしい履歴が記録されます。
{メジャー}.{マイナー}.{ビルド日}.{シーケンシャル} を使用します。Windows の場合、ほとんど自動的に処理する .NET プロジェクト用のユーティリティstampver.exeとUpdateVersion.exeを使用します。
自動化されたビルド システムでは、私は現在 Major.Minor.Build.X で I バージョンを使用しています。ビルドはシステム テストにヒットするたびに行われ、X はコードがビルドされているリポジトリからの最後の Subversion リビジョン番号です。必要に応じて特定のビルドのコードベースに簡単に戻ることができるため、Subversion では非常にうまく機能しているようです。
標準のバージョン番号システムはありません。一般的なテーマには、メジャー、マイナー、およびビルド番号があり、場合によってはポイント番号も含まれます (たとえば、バージョン 1.2 ポイント リリース 2 ビルド 1 の場合は 1.2.2.1)。バージョン番号の意味は非常に柔軟です。ただし、よくある選択は、マイナー バージョンまたはポイント リリース間の後方互換性を確保することです。
リリースは、ソース管理が許可されている限り、ソース管理されたファイルのセットにラベルを付けることによって行われるのがおそらく最善です。リリースを再作成することは、レーベルとビルドに同期するのと同じくらい簡単です。これは非常に便利です:)
Linux カーネルのバージョン番号付けシステムのバリエーションを使用します。
メジャー.マイナー.バグ修正
偶数マイナー番号は、少なくともテスト用に配布できるある程度安定したリリースを示し、奇数のマイナー番号は、開発者以外に配布すべきではない不安定/未テストのリリースを示します。
最も一般的な規則の 1 つは major.minor.bugfix で、追加のサフィックスはビルド番号またはプレリリースの指定 (例: アルファ、ベータなど) を示します。
私のチーム番号は、プロジェクトのマイルストーンに従ってビルドされます。ビルドは、開発の反復の最後に (数週間ごとに) QA グループに引き渡されます。暫定 CI ビルドには番号が付けられていません。Maven を使用しているため、これらのビルドには SNAPSHOT サフィックスで番号が付けられます。
何を決定しても、必ず文書化し、全員が理解できるようにしてください。また、リリース ブランチ ポリシーを文書化し、一貫して適用することをお勧めします。プロジェクトは 4 つしかありませんが、進行状況を追跡するのは非常に簡単です。
可能であれば、プロジェクトが共有されていない限り、同じビルド番号でバージョン管理されることを好みます。これにより、可動部分間の一貫性が高まり、製品リリースを構成するコンポーネントを簡単に識別できます。
workmad3 が述べているように、ビルド番号に関する一般的なルールは実際にはありません。私のアドバイスは、あなたのチーム/会社にとって意味のあるものを使用することです.
私が働いたことのある場所では、ビルドの番号付けをプロジェクトのマイルストーンとイテレーションに合わせています。
たとえば、メジャー = リリースまたはマイルストーン、マイナー = イテレーション、ビルド = ビルド番号 (プロジェクトの開始またはイテレーションの開始から)、リビジョン = もしビルドを再構築 (または分岐) する必要があります。
プロジェクトのいずれかがデータベースにアクセスするかどうかについては触れていませんが、アクセスする場合は、それが考慮すべき別の要因になる可能性があります。この質問への回答で説明されている他のものと同様の major.minor.bugfix.buildnumber スキームをほぼ同じロジックで使用しますが、データベース スキーマの変更には少なくともマイナーなインクリメントが必要であるという要件が追加されています。これにより、データベース スキーマの命名スキームも提供されます。たとえば、バージョン 1.2.3 と 1.2.4 は両方とも "1.2" データベース スキーマに対して実行できますが、バージョン 1.3.0 には "1.3" データベース スキーマが必要です。
現在、実際のバージョン管理はありません。svn ビルド番号とリリース日を使用します。(タグ名は release_081010_microsoft のようなものです 例)
古い製品では、メジャー.マイナー.サブのバージョン番号が使用されます
メジャー変更なし 6 か月ごとのすべてのリリース/機能リリースでのマイナー変更。Sub は、機能セットに影響を与えないすべてのものです - 主にバグ修正です。