当社では新製品の最初のリリースが近づいています。さまざまなコンポーネントすべてのバージョンを管理し、それらのコンポーネントを当社のソフトウェアのマーケティング部門のバージョンと相互参照する最善の方法を決定しようとしています。さまざまな理由から、当社の製品の最初のリリースは 10.1 であることがマーケティングによって決定されましたが、すべてのコンポーネントは最初は 1.0.0 から開始されます。通常のバグ修正、パッチ適用、継続的な開発作業により、異なるコンポーネントは同じバージョン番号ではなくなるため、マーケティング部門がバージョン 10.2 の時期であると判断した場合、1.1.54、1.2.32、1.8.2、もちろん、単純なスプレッドシートを使用することもできますが、それは最もユーザー フレンドリーな方法とは言えません。
これにはより「専門的な」方法がありますか、それとも単純なスプレッドシートが最適なオプションですか?
私が提案する主な原則は次のとおりです。できるだけ単純なスキームを使用してください。
自分自身、マーケティング部門、およびユーザーにとって物事を簡単にすることを検討してください。
リリースを行うときは、メジャー/マイナー バージョン番号をインクリメントし、それをすべてのコンポーネントにスタンプします。したがって、10.1 リリースでは、すべてのアセンブリのバージョン番号は 10.1.xx.yy になります。
次に、リリース内のさまざまなバージョンで問題を複雑にしたい場合 (たとえば、マイナー パッチ/更新、さまざまな顧客バリアント、または内部の毎日のビルドまたは CI ビルドなど) は、xx.yy フィールドを使用します。(多くの場合、たとえば、これら 2 つのフィールドにコンパイルの日時を自動的に入力するようにコンパイラーを設定できます)。
これは、コード バージョンに実際にリンクされた意味のある「マーケティング バージョン」を持っていることを意味し (そのため、あなたとマーケティング担当者は、混乱することなく特定のリリースについて話すことができます)、追加情報 (ビルド日など) を追加することができます。開発側で必要な場合のみ。
編集: PS コンポーネントが変更されていなくても、新しいバージョン番号で再構築してください。100 の同期されていないバージョン番号を追跡しようとすることは、回避可能な悪夢です。
すべてのコンポーネントを「ランダムな」バージョン番号のままにして、すべてのコンポーネントを網羅するマーケティング バージョンで 1 つのスーパー タグ/ラベルを作成してみませんか? これにより、マーケティング ビルドの合間にコンポーネントを更新し続け、ビルド バージョンをインクリメントし (顧客に表示される可能性のある 10.1.001、10.1.002 に移動する必要はありません)、マーケティング ビルドを追跡することもできます。また、次のマーケティング ビルド用に一部のコンポーネントを更新し、他のコンポーネントを更新しない場合はどうなりますか? バージョン番号を更新するためだけに、これらのコンポーネントをビルドする必要がありますか?
ソース管理システムによっては、これらのすべてのコンポーネントを異なるバージョンで含む、指定された名前/バージョンのリリースを簡単に作成できるはずです。
また、すべての画面、スプラッシュ画面、ツールバーなどに表示されるように、1 つのプロパティ ファイルをマーケティング ビルド番号で更新するだけで済みます。システム。これにより、すべてのコンポーネントのビルド番号を維持しながら、顧客に表示される番号を簡単に変更できます。さらに、次のバージョンが 10.2 ではなく「クリムゾン」になるとマーケティングが判断した場合はどうなるでしょうか。
私が働いていた場所では、ソフトウェアのバージョン番号を公式の公開 (つまり、マーケティングの) リリース番号と一致させるように強制していました。「10.1」を出荷したい場合は、ソフトウェアのバージョン リソースをそのように設定していました。リリース ビルドの一部として。