2

バージョン番号と、Maven および SVN との分岐/マージに関する確実な情報を見つけようとしています。

私のプロジェクトでは、次の Maven バージョン ルールを使用します。

<major>.<minor>.<revision>([ -<qualififer> ] | [ -<build> ])

私のMavenリリースは次のとおりで、トランクとリリースタグにスナップショットがあります

trunk:    1.0.0-SNAPSHOT

tag:      1.0.0

trunk:    1.0.1-SNAPSHOT

tag:      1.0.1

etc....

質問:

  1. バグ修正を行うために (リリース タグから) ブランチを作成するとします。このパッチをリリースする場合、maven リリース プラグインは何番を発行しますか? どのタグ名を取得しますか? 変更をトランクにマージすることに関する推奨事項はありますか?

  2. Maven のバージョン番号を変更する標準的な方法は何ですか? メジャー、マイナー、およびビルド番号はいつインクリメントされますか?

推奨されるアプローチに光を当てることができる本やドキュメントはありますか?

4

3 に答える 3

3

Better Builds with Maven - Mergere Library Pressからの引用。

セクション 3.6。依存関係の競合の解決とバージョン範囲の使用:

ここに画像の説明を入力

バグ修正を行うために (リリース タグから) ブランチを作成するとします。このパッチをリリースする場合、maven リリース プラグインは何番を発行しますか? どのタグ名を取得しますか? 変更をトランクにマージすることに関する推奨事項はありますか?

Maven が生成しmvn release:prepareたものが気に入らない場合は、特定のバージョン名 (リリース バージョン、タグ バージョン、次のトランク バージョンなど) を入力する機会が得られます。ブランチからパッチ リリースをビルドするなどの特別なケースでは、通常は自分でバージョン名を設定します。

  • 変更をトランクにマージする必要がない場合 (ブランチからビルド リリース)、1.0.1-1 または 1.0.1-patch-1 を使用します。

  • 変更をトランクにマージする必要がある場合 (トランクからのビルド リリース)、大きな変更の場合は 2.0.0 を使用し、マイナーな変更の場合は 1.1.0 を使用し、バグ修正の場合は 1.0.2 を使用します。

Maven のバージョン番号を変更する標準的な方法は何ですか? メジャー、マイナー、およびビルド番号はいつインクリメントされますか?

上の図を参照してください。

アップデート：

はい、これはMavenのバージョン管理のもう1つの紛らわしい部分です。私にとって、この図はその下に書かれている内容と矛盾しています。パッチのリリース後にビルド番号が増分されることを示しています。しかし、図に示すように、バージョン文字列のバグ修正部分はそれが目的だと思いましたか??

Maven バージョン範囲の目的は、できるだけ多くのユース ケースをカバーすることです。それをどのように使用するかは、完全にあなた次第です。ここでのポイントは、どちらがより合理的かということです。元の投稿で述べたように、チームが 2 つのワーク ストリームを同時に維持する必要があるような特別なケースで使用されます (トランクのメイン ワーク ストリームとブランチの 2 番目のワーク ストリーム)。

このシナリオを例にとると、長時間の作業の後、リリース 1.0.6 をビルドしてクライアントにデプロイします (SVN では、1.0.6 がタグ付けされ、トランクが 1.0.7-SHAPSHOT にインクリメントされます。これは、次に予想されるリリース バージョンを意味します)。は 1.0.7 です)、trunk で継続的に開発されています。それから 2 週間後、リリース 1.0.6 でバグが報告され、緊急の修正が必要になったため、タグ 1.0.6 からブランチを作成し、バグを修正してブランチをトランクにマージします。ここで、クライアント用のパッチ リリースをビルドする必要があります。前回のビルド (2 週間前) からトランクが大幅に変更されたため、ブランチからこのパッチ リリースをビルドする必要があります。当然のことながら、このパッチ リリースには好きなもの (つまり 1.0.7) を使用できます。その結果、トランクのバージョンを手動で変更する必要があります (1.0.7-SHAPSHOT から 1.0.8-SNAPSHOT へ)。ただし、このパッチ リリースには 1.0.6-patch-1 を使用することをお勧めします。

図に矛盾はありません。ビルド番号はこのシナリオでは完璧です。これは、「ビルド番号は、パッチが適用されたビルドを示すためにリリース後に増分される」ことを意味します。これにより、すぐにリリースできる開発バージョン (1.0.7-SNAPSHOT -> 1.0.1) ではなく、既にリリースされているバージョン (1.0.6 -> 1.0.6-patch-1) のバージョン ターゲットをインクリメントする 2 回目のチャンスが得られます。 7）。

于 2012-07-20T00:06:11.733 に答える
2

この場合、別の番号付けスキーマを作成することをお勧めします。したがって、1.0.0-BFBのような名前の1.0.0タグからブランチを作成するとします。Mavenアーティファクトのバージョンは次のようなものを使用します：

1.0.0.1-SNAPSHOT

このアーティファクトをリリースすると、バージョン番号は次のようになります。

1.0.0.1

これは、このように1.0.0行に複数の変更を加えることで簡単に拡張できる、単一の変更に対するソリューションです。1.0.0タグからブランチを作成し、MB-1.0.0のように名前を付けます。アーティファクトのバージョンは、次のように実行できます。

1.0.0.1-SNAPSHOT
1.0.0.1
1.0.0.2-SNAPSHOT
1.0.0.2
1.0.0.3-SNAPSHOT
etc.

デフォルトでは、Mavenのタグ名はartifactIdの名前とバージョンによって計算されます。

このようなメンテナンスブランチの作成は、次のようなリリースプラグインによって実行できます。

mvn -B -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DreleaseVersion=1.0.1-SNAPSHOT -DbranchName=MB-1.0.0 release:branch

この状況を処理するためのデフォルトの解決策は、developmentVersionまたはreleaseVersionも使用できるリリースプラグインのパラメーターを使用することです。これは、リリースを行う前にそれを知っている場合にのみ機能します。

ただし、リリースを作成し、後でマイナーバージョンまたはメジャーバージョンを変更することを決定した通常のケース。したがって、リリースプラグインは次のように使用できます。

mvn org.apache.maven.plugins:maven-release-plugin:2.3.2:update-versions -DdevelopmentVersion=WhatEverVersionYouLike

または、versions-maven-pluginを使用してバージョン番号を更新できます。

于 2012-07-19T17:42:11.743 に答える
0

リリース時にアーティファクトに与えるバージョンを完全に制御できます。

一般に、major.minor.patch バージョン管理スキームでは、バグ修正、マイナー - 後方互換性を壊さない新機能、メジャー - 後方互換性のない変更、および新しいメジャー機能に対して、パッチ部分がインクリメントされるという考え方です。

于 2012-07-19T17:38:16.120 に答える