3

次のシナリオを考えてみましょう。mavenビルドツールやsvnバージョン管理用の他のツールとして使用して開発中のプロジェクトがあります。

ある時点で、「おそらく」リリースの準備ができていると判断し、svnタグを設定して次のようにマークします。release candidate

+ Trunk (0.0.1-SNAPSHOT)
|
+----------------------------+ Branch "release-candidate" (0.0.1-SNAPSHOT)
|                            | (goes to QA for testing)
+ Trunk (0.0.2-SNAPSHOT)     | 
| (development continues)    + Tag "release-0.0.1" (0.0.1)
....                           (deploy this revision)

この時点pom.xmlで、を新しい開発バージョンで更新する必要があります。はrelease-candidate、QAのテストが完了し、リリースの準備ができていると宣言するまで、スナップショットバージョンを保持します。そうして初めて、実際のリリースとデプロイがタグ/ブランチで実行されます。

リリース候補がテストされている間、開発はトランクで続行できます。

この2ステップのリリースシナリオは、Mavenビルドで実現できますか？プラグインはこれに十分ですか、それとも他のreleaseプラグインが必要ですか？

4

1 に答える 1

3

Maven Release Plugin は、Maven プロジェクトをリリースするためのデファクト スタンダードであり、このための具体的なワークフローを強制します。ご覧のとおり、かなり異なる前提がありますが、ここで Maven の規則に適合させようとする場合、Maven Release Plugin はここですべての作業を行います。

まず第一に、目標は、新しい開発の準備ができているrelease:branchバージョンをバンプしながら、いくつかのバージョン ライン ブランチを作成するのに役立ちます。trunkただし、私の意見では、release-candidate次のリリースごとにこのブランチ名 (ここ) を共有することは、明らかに良い考えではありません。むしろ、ここでの標準的な方法は、リリースごとにリリース ブランチを行うことです。実際の最終リリースの少し前に内容が洗練されます。0.0.1したがって、たとえばブランチ名は問題ありません。ちなみに、release:branch目標<scm />はPOMのタグを更新して、作成したばかりのブランチを指すようにするため、共有ブランチを使用することは-もう一度-良い考えではありません。

リリース候補を磨き上げた後、Maven の通常のように、かなり標準release:prepare的なrelease:perform呼び出しと branch からの呼び出しを使用して、実際のリリースを行うことができます。タグを作成したり、ものをデプロイしたりします。

そして今、本当にこのブランチ名を固定したい場合 (テスターの必要性か何かのために) いつでもsvn:externalsThing and updatesrelease-candidateエイリアスを使用して、常に現在のリリース候補ブランチを指すことができます。

于 2012-05-10T07:49:58.547 に答える