製品管理とアセンブリバージョン

Question

私たちは、当社の新製品の最初のリリースに近づいており、さまざまなコンポーネントのすべてのバージョンを管理し、それらのコンポーネントをマーケティング部門と相互参照する最良の方法を決定しようとしています私たちのソフトウェアのバージョンです。さまざまな理由から、マーケティングでは、製品の最初のリリースは10.1になると判断されていますが、すべてのコンポーネントは最初1.0.0から始まります。通常のバグ修正とパッチ適用と継続的な開発作業によって、異なるコンポーネントが同じバージョン番号になることはなくなります。したがって、マーケティング部門はバージョン10.2の時期になると、1.1.54,1.2.32,1.8.2、明らかに、私はシンプルなスプレッドシートを使用することができますが、これはユーザーフレンドリーな方法ではありませんし、テクニカルサポートの人々がコンポーネントのバージョンを相互参照するための問題があります（顧客はバージョン10.1,10.2 、など）。

これには「プロフェッショナル」な方法がありますか、単純なスプレッドシートが最適ですか？

Answer 1

私が働いていた場所では、ソフトウェアのバージョン番号を公式（つまりマーケティングの）リリース番号と一致させることにしました。もし彼らが "10.1"を出荷したいのであれば、バージョンリソースを、リリースビルドの一部として

Answer 2

すべてのコンポーネントを「ランダム」バージョン番号にして、すべてのコンポーネントを含むマーケティングバージョンで1つのスーパータグ/ラベルを作成してみませんか？これにより、マーケティングビルド間のコンポーネントの更新を維持し、ビルドバージョンを増やすことができます（顧客に見える10.1.001、10.1.002に行かなくても、マーケティングビルドを追跡することができます）。また、次のマーケティングビルドのためにいくつかのコンポーネントを更新し、他のコンポーネントを更新しないとどうなりますか？バージョン番号を更新するためにこれらのコンポーネントをビルドする必要がありますか？

ソース管理システムによっては、異なるバージョンのこれらのコンポーネントすべてを含む指定された名前/バージョンのリリースを簡単に作成することができます。

1つのプロパティファイルをマーケティングビルド番号で更新するだけで、スクリーン、スプラッシュスクリーン、ツールバーなどのすべてについて表示されるようにする必要があります。そのような設定をしていない場合は、そのようなシステムに移動する。これにより、すべてのコンポーネントビルド番号を維持しながら、顧客の可視番号を簡単に変更できます。さらに、次のバージョンが10.2になるとはマーケティングが判断したときに何が起こるのですか？ "Crimson？"

Answer 3

私が示唆している主な原則は次のとおりです。

あなた自身、マーケティング部門、およびユーザーのためのものを簡単に作成することを検討してください。

リリースを行うときは、メジャー/マイナーバージョン番号を増分し、それをすべてのコンポーネントにわたってスタンプします。したがって、10.1リリースでは、すべてのアセンブリにバージョン番号10.1.xx.yyがあります。

次に、リリース内で異なるバージョンの問題を複雑にしたい場合（たとえば、マイナーパッチ/アップデート、異なる顧客バリアント、または内部の日別またはCIビルドの場合）、xx.yyフィールドを使用します。 （多くの場合、たとえば、コンパイルの日付/時刻などでこれら2つのフィールドを自動的に埋めるようにコンパイラを設定できます）。

これは、コードバージョンに実際にリンクされている意味のある「マーケティングバージョン」を持っていることを意味します（したがって、あなたとマーケティングは混乱することなく特定のリリースについて話すことができます） ）（もし必要ならば）開発者側で必要な場合。

編集：P.S.コンポーネントが変更されない場合でも、新しいバージョン番号で再構築してください。同期外れしたバージョン番号を追跡しようとするのは避けられない悪夢です。