2

maven multi-module6 つ以上の子モジュールを含むプロジェクトがあります。3 人のチームがそれぞれ 2 つのタスクとして並行して作業している場合sub-modules、バージョン番号を増やす方法。

一方、私はMajor.minor.patch-metaリリース サイクルでのバージョン番号付けの形式に従っています。

Project A
   -- sub-module-assembler 
      pom.xml
   -- sub-module-1
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-2 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-3 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-4 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-5 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
   -- sub-module-6 
        -sub-sub-module-1 pom.xml 
        -sub-sub-module-2 pom.xml 
      pom.xml
--pom.xml

でのバージョン番号の増減の正確な使用法parallel programming。これで通知される重要なことはsub-modules、そのプロジェクトの一部が他のプロジェクトに完全に依存するsub-moduleことですが、その場合、開発が並行して行われている間に正確にバージョン番号を付ける方法注文 ？

以下については明確ではありませんが、これはバージョン番号付けの正しい方法ですか

  1. meta releaseアルファ、ベータ、ガンマなどのバグ修正の場合に行う必要がある場合は、

  2. 0.1.1-alpha、0.1.2-alphaなどを使用しているのに、apatch releaseの完了の場合にaを実行する必要がありますか?feature[sub-sub-module-x]sub-modulesecond level+ sub-modules

  3. minor releaseたとえば、 0.2.0-alpha 、 0.2.0-RC などの完了の場合に行う必要がありsub-moduleます。
  4. したがって、すべての RC の 0.2.0-RC + 0.3.0-RC + 0.4.0-RC などを統合した後、major releaseas 1.0.0-RTM などを実行する必要があります。

したがって、上記の流れを理解するのは少し混乱します..

build numberingclear を維持するために、プロジェクトでを自動化する方法はありますかbuild release numbers。解決策を提供してください。

ありがとう

4

1 に答える 1

1

すべてのバージョン管理戦略に対する答えはないと思います。ただし、状況に適した戦略を選択するのに役立つヒントをいくつか試してみましょう.

プロジェクトはかなり大きく見えます。私が最初に行うグループ分けは、責任によるものです。特定の開発チームに限定されているモジュールはありますか? それとも、全体が「オールインワン」に維持されていますか? 少しずつ分けていただけると幸いです。モジュールの責任について理解したら、ライフサイクルを定義する必要があります。リリース (またはバグ修正、パッチ) は、誰によって、どのように、どのくらいの頻度で作成されますか? 全員が同じリズムに従えば、1 つのバージョンを共有してツリー全体をリリースできます。しかし、通常、これは大規模なプロジェクトには当てはまりません。また、多くの人が 1 つのバージョンを共有すると、開発中に副作用が発生します。

完全なツリーを一度にリリースする予定がない場合は、さらに分割することもできます。共通の親 pom.xml を引き続き使用できます (ただし、リリース済みバージョンのもの)。

親 pom.xml でモジュールの 1 つのバージョンを定義し、それを継承します。したがって、サブモジュールに個別のバージョンはありません。さらに、他のモジュールに依存するすべてのチームは、SNAPSHOT 依存関係を使用して他のチームの作業を行うべきではありません。彼らはリリースされたバージョン (BETA または RC1) のみを使用できます。ビルドの再現性を維持することが重要です。例: 「自分が担当していないアーティファクトへのスナップショットの依存関係はありません (いつ、何を変更するかを制御します)」

バージョニング自体に関しては、よりシンプルなオプションの方が良いかもしれません。すべてのメタ情報は、実際の状態を混乱させるだけでしょうか?

また、デプロイ パイプラインを描画することも役立つ場合があります。つまり、どのモジュールが最初に来るか、どのモジュールがそれに依存するかなどです。1 つのモジュールの変更量によって、バージョンがどのように変更されるか (メジャー、マイナー、パッチの変更) が定義されます。これらの変更がモジュール全体に反映されない場合 (API は安定したままであり、それが目標です)、次のモジュールはパッチ リリースのみを行う可能性があります。

まだ何もリリースしていない場合は、事前に計画してください。通常、すべての反復は API の変更です (したがって、実際にはメジャー リリースになります)。これにより、バージョン 18.0.0 がリリースされます (18 回の反復の後)。そのため、通常、マイナー バージョンは反復を示すために使用され、パッチ バージョンはそのリリースを安定させるためのいくつかの修正を示します。そのため、メジャー バージョンは、技術的な側面よりもマーケティングの側面から選択されます。

また、構築するソフトウェアの種類 (製品、社内ソリューション、ランドスケープ用の追加サービス) によっても多少異なります。製品にはより明確なバージョン管理があり、通常、META 部分を使用してイテレーションを示し、major.minor.patch 番号を使用して何が起こっているかを示します。その戦略 (「期待される変更を示す」) は、あなたが行っていることにも役立つでしょうか?

だからうまくいけば、これはあなたが最初に持っていたよりも多くの質問を提起しませんでした:)

于 2014-05-05T12:03:26.940 に答える