![[S] Subversion](/images/svn-name-banner.svg)
[このドキュメントの単一ページ版もご覧いただけます。]
このドキュメントは、一般的に、特異性の高い順に3つのパートに分けることができます
Subversion のリリース管理者は、release.py という名前の Python スクリプトでコード化された一連の手順を使用します。このスクリプトを使用して、リリースプロセスのほとんどの自動化された手順を実行できます。-hオプションを使用して実行すると、詳細情報を得ることができます。
以下のプロジェクト固有のガイドラインに加えて、リリース管理者を目指す人は、一般的なApache リリースポリシーも読んでおくとよいでしょう。時々パッチワークのように見えるかもしれませんが、一般的なベストプラクティスと、Subversion が大規模な ASF エコシステムにどのように適合するかについての良いアイデアを与えてくれます。
Subversion は「MAJOR.MINOR.PATCH」のリリース番号を使用します。「偶数 == 安定版、奇数 == 不安定版」の規約は使用しません。修飾されていないトリプレットは、安定版リリースを示します。
1.0.1 --> first stable patch release of 1.0 1.1.0 --> next stable minor release of 1.x after 1.0.x 1.1.1 --> first stable patch release of 1.1.x 1.1.2 --> second stable patch release of 1.1.x 1.2.0 --> next stable minor release after that
リリースの順序は半非線形です。1.0.3 は 1.1.0 の後に出る可能性があります。しかし、パッチラインが廃止されたことを宣言し、次のマイナーリリースにアップグレードするように人々に伝えるため、「半」非線形に過ぎません。したがって、長期的には番号付けは基本的に線形です。
番号は複数の桁を持つことができます。たとえば、1.7.19 は 1.7.x ラインの 19 番目のパッチリリースです。これは 1.7.2 の 3 年後、1.7.20 の 3 か月前にリリースされました。
Subversion のリリースは、バージョン番号の後にテキストで修飾される場合があります。これらはすべて、リリース前のプロセスのさまざまなステップを表します。安定度の低いものから高いものへの順に
| 修飾子 | 意味 | 例 | の出力svn --version |
|---|---|---|---|
| Alpha | 問題があること、または発生することが予想されることを知っていますが、関心のある個人からのテストを募集します。 | subversion-1.7.0-alpha2 | バージョン 1.7.0 (Alpha 2) |
| Beta | 問題が発生するとは予想していませんが、念のため注意してください。 | subversion-1.7.0-beta1 | バージョン 1.7.0 (Beta 1) |
| RC (リリース候補) | このリリースは、最終的な提案バージョンになる候補です。深刻なバグが見つからなかった場合、-rcタグが削除され、このリリースの内容が安定版と宣言されます。 | subversion-1.7.0-rc4 | バージョン 1.7.0 (リリース候補 4) |
「'make install」subversion-1.7.0-rc1 を実行すると、もちろん「1.7.0」としてインストールされます。修飾子はリリースのメタデータです。後続の各プレリリースリリースで前のリリースを上書きし、最終リリースで最後のプレリリースを上書きする必要があります。
ワーキングコピーのビルドの場合、心配する必要のある tarball 名はありませんが、「'svn --version」は特別な出力を生成します。
version 1.7.1-dev (under development)
バージョン番号は、プロジェクトが目指している次のバージョンです。重要なのは、「開発中」と言うことです。これは、ビルドがワーキングコピーから来たことを示しており、バグレポートで役立ちます。
正式な安定化期間に入る前に、新しい機能を広範囲にテストしてもらいたい場合、アルファおよびベータ tarball をリリースすることがあります。「alpha1」、「alpha2」などのリリースがあったとしても、ベータリリースを行う必要はありません。「rc1」に直接ジャンプできます。ただし、ベータ版が役立つ状況もあります。たとえば、UI の決定が不明確で、正式なリリース候補に固める前に、より多くのユーザーからのフィードバックを得たい場合などです。
アルファ版とベータ版は、テストを手伝いたい、そして最終リリース前に互換性のない変更がある可能性があることを理解している人のみ対象です。署名要件は、リリース管理者の裁量に委ねられます。通常、RM は各プラットフォームに 1 つまたは 2 つの署名のみを要求し、テスターがテストで軽微な障害が明らかになっても、コードが他の人によるテストを行う価値があるほど堅牢であると考える限り、署名できることをテスターに伝えるように要求します。RM は、署名者が署名とともにエラーの説明を含めるように要求する必要があります。これにより、アルファ版またはベータ版のリリースが発表されるときに問題を公開できます。
アルファ版またはベータ版が公に発表された場合、配布パッケージャーはパッケージ化しないように強く警告する必要があります。良いモデルについては、Hyrum K. Wright からのこのメールを参照してください。
当社の互換性ルール（下記で詳しく説明）は、最終 x.y.0 バージョンが承認され、リリースされた後にのみ適用を開始します。トランクまたはアルファ/ベータ/rc プレリリースに表示された API、ワイヤープロトコル、およびディスク上の形式は、いかなる互換性の約束にも左右されません。正当な理由が見つかった場合は、最終リリースまで任意に変更する可能性があります。快適でないインターフェイスまたはシリアル化形式を完全に削除することさえあります。
これは永続的なデータ（ワーキングコピーとリポジトリ）にとっては特に問題です。最終リリースでは、レガシー形式のアップグレードパス（コードパスまたは指定されたスクリプト）を提供しない可能性があるためです。（もちろん、プレリリースをテストする開発者とユーザーのために、そのようなスクリプトを提供する可能性があります。しかし、そうすることを義務付けるものではありません。）したがって、プレリリースは、長期的な保管を目的としたデータで絶対に信頼しないでください。
同時に、API デザインのバグを指摘するのに最適な時期は、リリースされて確定する前、つまり、初期設計とプレリリースの段階であることを読者に思い出させたいと思います。
リリースまたは候補リリースが、コード以外の問題（たとえば、パッケージングの不具合）のために迅速に再発行される必要がある場合は、tarball が署名によって承認されていない限り、同じ名前を再利用してもかまいません。ただし、署名付きで標準の配布領域にアップロードされている場合、または再発行がユーザーが実行する可能性のあるコードの変更が原因である場合は、古い名前を破棄し、次の名前を使用する必要があります。
リリース予定の tarball が公開されてユーザーに発表される前に古い名前が破棄された場合、破棄された名前は非公開リリースと見なされ、ドキュメント（CHANGES やタグのログメッセージなど）を更新してその旨を反映する必要があります。（例として 1.8.7 を参照してください。）破棄されたリリースのタグと tarball はリポジトリの履歴に残りますが、一般的な使用はサポートされていません（それどころか、リリースブロッカーのバグがあることがわかっています）。
Subversion は、APR と同じガイドライン（https://apr.apache.org/versioning.html を参照）と、後述するいくつかの拡張機能に従って、厳密な互換性を維持します。これらのガイドラインは、さまざまな形式のクライアント/サーバー間の相互運用性を確保し、ユーザーが MAJOR.MINOR Subversion リリース間で明確なアップグレードパスを確保するために設けられています。
互換性は、API や ABI からコマンドライン出力形式まで、さまざまな軸にまたがることができます。既存のアーキテクチャを新しい機能をサポートするために変更する必要性と、可能な限り現在のユーザーをサポートする必要性のバランスを取ろうとしています。一般的な考え方は次のとおりです
同じ MAJOR.MINOR ラインの異なるパッチリリース間のアップグレード/ダウングレードでは、コードが壊れることはありません。バグ修正が消えたり再表示されたりする可能性がありますが、API シグネチャとセマンティクスは同じままです。（もちろん、セマンティクスはバグ修正に適した些細な方法で変更される可能性がありますが、呼び出しコードの調整を強制するような方法では変更されません。）
同じメジャーライン内の新しいマイナーリリースへのアップグレードでは、新しい API が表示される可能性がありますが、API は削除されません。古いマイナー番号で記述されたコードは、そのラインのそれ以降のマイナー番号で動作します。ただし、新しい API を利用する新しいコードが記述されている場合、その後のダウングレードは機能しない可能性があります。
（ごくまれに、古い API の動作をわずかに変更する必要があるバグが見つかることがあります。これは通常、さまざまなコーナーケースやその他の一般的でない領域でのみ現れます。これらの変更は、各 MAJOR.MINOR リリースのAPI エラータとして文書化されています。）
メジャー番号が変更されると、すべてがなくなります。これは API を完全にリセットする唯一の機会であり、インターフェイスを不用意に削除しないように努めますが、少し整理するために使用します。
Subversion は、クライアント/サーバー間の互換性の問題をカバーするために APR ガイドラインを拡張しています
サーバー（またはクライアント）のパッチリリースまたはマイナーナンバリリースは、同じメジャーラインのクライアント（またはサーバー）との互換性を決して損ないません。ただし、リリースによって提供される新機能は、接続の反対側を対応するアップグレードなしではサポートされない場合があります。特に ra_svn コードを更新する場合は、これらの原則に従ってください。
フィールドは任意のタプルに追加できます。古いクライアントは単にそれらを無視します。（現在のところ、マーシャリングの実装では、タプルのオプション部分に数値またはブール値を入れることはできませんが、それを変更してもプロトコルには影響しません。）
このメカニズムは、情報がAPI呼び出しに追加されたときに使用できます。
接続確立時に、クライアントとサーバーは機能キーワードのリストを交換します。
このメカニズムは、パイプラインの導入やAPI呼び出しからの情報の削除など、より複雑な変更に使用できます。
新しいコマンドを追加できます。サポートされていないコマンドを使用しようとすると、エラーが発生し、それをチェックして対処できます。
プロトコルバージョン番号を上げて、古いクライアントまたはサーバーの正常な拒否を許可したり、クライアントまたはサーバーが古い方法で処理する必要がある場合を検出したりできるようにします。
このメカニズムは最後の手段であり、機能キーワードの管理が困難すぎる場合に使用します。
ワーキングコピーとリポジトリの形式は、同じマイナーシリーズのすべてのパッチリリースで後方互換性と前方互換性があります。それらは同じメジャーシリーズのすべてのマイナーリリースで前方互換性があります。ただし、マイナーリリースでは、以前のマイナーリリースでは動作しないワーキングコピーまたはリポジトリを作成できます。ここで、「作成」とは「アップグレード」も意味する場合があります。
Subversionでは、リリース時に特別な扱いを必要とするセキュリティ問題が報告または発見されることがあります。一般的なリリースプロセスは同じであり、開発者がこれらの問題をどのように扱うかの詳細は他の場所で説明されています。
Subversionはバイナリパッケージを配布せず、代わりにサードパーティのパッケージャーに依存しています。幸いなことに、多くの個人や企業がこの点で努力を惜しまず、私たちは彼らの努力に感謝しています。
サードパーティのパッケージャーである場合、バグ修正やその他の変更がユーザーにとって重要であり、標準のSubversionリリースサイクルよりも迅速にユーザーに提供したい場合があります。または、対象ユーザーに役立つ一連のパッチをローカルで管理している場合があります。可能であれば、パッチプロセスを使用して、変更が受け入れられ、トランクに適用され、通常のSubversionリリーススケジュールでリリースされることをお勧めします。
ただし、Subversion開発者コミュニティに広く受け入れられない変更を加える必要がある場合、または未リリースの機能への早期アクセスを提供する必要がある場合は、以下のガイドラインに従う必要があります。これらは、ユーザーコミュニティの混乱を防ぎ、カスタムリリースと公式Subversionリリースの両方を可能な限り成功させることを目的としています。
まず、ASF商標ポリシーに従っていることを確認してください。カスタムリリースによって発生する可能性のある混乱を軽減するために、標準のSubversionリリースからリリースを区別する必要があります。
次に、変更を追跡し、カスタム変更をメインラインSubversionにマージする可能性を考慮して、公開Subversionリポジトリにブランチを作成することを検討してください。（まだお持ちでない場合は、コミットアクセスを要求してください。）
第三に、カスタムリリースがメインラインSubversionに関連しないバグレポートを生成する可能性が高い場合は、カスタムリリースのユーザーと連絡を取り合い、それらのレポートを傍受してフィルタリングできるようにしてください。しかしもちろん、最良の選択肢は、そもそもそのような状況にならないことです。カスタムリリースがメインラインSubversionから逸脱するほど、混乱を招きます。カスタムリリースを作成する必要がある場合は、可能な限り一時的で非発散的になるように努めてください。
新しい、改善されたバージョンのAPIが導入された場合、少なくとも次のメジャーリリース（2.0.0）までは、互換性のために古いバージョンが残ります。ただし、古いバージョンを非推奨としてマークし、新しいバージョンを指すことで、可能な限り新しいAPIに書き込むように人々に知らせます。非推奨にする場合は、非推奨が導入された後のリリースを言及し、新しいAPIを指します。可能であれば、古いAPIドキュメントを新しいドキュメントへの差分で置き換えてください。たとえば
/**
* Similar to svn_repos_dump_fs3(), but with a @a feedback_stream instead of
* handling feedback via the @a notify_func handler
*
* @since New in 1.1.
* @deprecated Provided for backward compatibility with the 1.6 API.
*/
SVN_DEPRECATED
svn_error_t *
svn_repos_dump_fs2(svn_repos_t *repos,
svn_stream_t *dumpstream,
svn_stream_t *feedback_stream,
svn_revnum_t start_rev,
svn_revnum_t end_rev,
svn_boolean_t incremental,
svn_boolean_t use_deltas,
svn_cancel_func_t cancel_func,
void *cancel_baton,
apr_pool_t *pool);
メジャーリリース番号が変更されると、シリーズで「最良」の新しいAPIは通常、以前のすべてのAPIを置き換え（その機能を含んでいると仮定して）、元のAPIの名前を受け継ぎます。したがって、1.1.xで「svn_repos_dump_fs」を非推奨としてマークしても、2.0.0に「svn_repos_dump_fs」がないという意味ではなく、関数のシグネチャが異なるだけです。1.1.xではsvn_repos_dump_fs2（またはsvn_repos_dump_fs3など）が保持するシグネチャになります。番号付きの接尾辞の名前は消え、単一の（キラキラした新しい）svn_repos_dump_fsが再び存在します。
この置換戦略の1つの例外は、古い関数にそもそもまったく不満な名前が付いている場合です。非推奨はそれを修正する機会です。新しいAPIにまったく新しい名前を付け、古いAPIを非推奨としてマークし、新しいAPIを指します。次に、メジャーバージョンの変更時に、古いAPIを削除しますが、新しいAPIの名前を古い名前に変更しません。新しい名前が適切であるためです。
マイナーおよびメジャーナンバリリースは、リリース前に安定化期間を経て、リリース後は保守（バグ修正）モードになります。リリースプロセスを開始するには、最新のトランクに基づいて「A.B.x」ブランチを作成します。
新しいA.B.0リリースの安定化期間は通常4週間続き、保守的なバグ修正と致命的な問題の発見を可能にします。安定化期間は、バージョンA.B.0-rc1のリリース候補tarballで始まります。ブロックバグが修正されると、さらにリリース候補tarballが作成される場合があります。たとえば、言語バインディングのセットが壊れていることが判明した場合、修正されたときに新しいリリース候補を作成して、それらの言語バインディングをテストできるようにするのが賢明です。
A.B.xブランチが作成されたら、ソースコードの変更を直接コミットすることは決してありません。変更は、次のセクションで説明するプロセスによって投票された後、トランクからA.B.xブランチにバックポートされます。
安定化期間の最終週の初めに、最後のものからペンディング中の致命的な変更がある場合は、新しいリリース候補tarballを作成する必要があります。安定化期間の最終週は、重大なバグ修正のために予約されています。軽微なバグの修正は、A.B.1リリースに延期する必要があります。重大なバグとは、エッジケースではないクラッシュ、データ破損の問題、重大なセキュリティホール、または同様に深刻なものです。
状況によっては、安定化期間が延長される場合があります
svn-soak-management.png
バグを修正するために潜在的に不安定な変更を加える必要がある場合は、4週間の安定化期間全体が再開されます。潜在的に不安定な変更とは、Subversionの多くの部分に予測不可能な方法で影響を与える可能性のある変更、または大量の新しいコードを追加することに関係する変更です。互換性のないAPI変更（新しいリリースがA.0.0リリースの場合にのみ許可される）は、潜在的に不安定な変更と見なす必要があります。
安定化期間の最終週に重大なバグ修正が行われた場合、最終週が再開されます。最終的なA.B.0リリースは、1週間前に作成されたリリース候補と常に同一です（以下で説明する例外を除く）。
A.B.0リリースが完了すると、バグ修正が必要な場合にパッチリリース（A.B.1、A.B.2など）が続きます。パッチリリースには4週間の浸透は必要ありません。保守的な変更のみがラインに入るためです。
特定の種類のコミットは、浸透期間を再開せずにA.B.0に、またはテストスケジュールまたはリリース日に影響を与えずに後のリリースに入れることができます
投票なし
の変更STATUSファイル。
ドキュメントの修正。
たとえば、リリースのローリングおよびリリースブランチの作成と保守にリストされている手順など、リリース簿記の通常の変更。
の変更dist.shリリースマネージャーによる、または承認されたもの。
のメッセージ翻訳の変更.poファイルまたは新しいものの追加.poファイル。
投票あり
にのみ影響を与えるものtools/, packages/、またはbindings/.
エラーメッセージや使用メッセージなど、書式設定文字列「%」コードとその引数が変更されていない限り、印刷された出力の変更。
注：メッセージ翻訳の変更に関する要件は、Cコードのテキストメッセージよりも緩いです。の書式指定子を変更する.poファイルは、その妥当性を機械的に（GNU gettextのmsgfmtの-cフラグを使用して）チェックできるため許可されています。これは、GNU gettextが使用されている場合、ビルド時に行われます。
もちろん、コアコードの変更には投票が必要であり、浸透期間またはテスト期間を再開します。そうしないと、変更が十分にテストされない可能性があるためです。
A.B.xラインへの変更は、最初にA.B.x/STATUSファイル。各提案は、短い識別ブロック（たとえば、トランクまたは関連ラインのコミットのリビジョン番号、または問題番号）、変更の簡単な説明、A.B.xにあるべき理由の最大1行の正当性、いくつかのメモ/懸念事項、そして最後に投票で構成されます。メモと懸念は、読者が方向性を理解するのに役立つ簡単な要約を目的としています。STATUS実際の議論にはファイルを使用しないでください。代わりにdev@を使用してください。
次に例を示します。おそらくエントリがこれまでで最も複雑なものです。
* r98765 (issue #56789)
Make commit editor take a closure object for future mindreading.
Justification:
API stability, as prep for future enhancement.
Branch: 1.8.x-r98765
Notes:
There was consensus on the desirability of this feature in
the near future; see thread at http://... (Message-Id: blahblah).
Merge with --accept=mc.
Concerns:
Vetoed by jerenkrantz due to privacy concerns with the
implementation; see thread at http://... (Message-Id: blahblah)
Votes:
+1: ghudson, bliss
+0: cmpilato
-0: gstein
-1: jerenkrantz
誰でも投票できますが、完全コミッターと、関係する分野の部分的コミッターのみが拘束力のある投票権を持っています。コミッターが非拘束力のある投票（たとえば、指名されたエリア外の変更に投票する部分的コミッターなど）を行う場合は、次のように、自分の投票を非拘束的として注釈を付ける必要があります
* r31833
svndumpfilter: Don't match prefixes to partial path components.
Fixes #desc4 of issue #1853.
Votes:
+1: danielsh, hwright
+1 (non-binding): stylesen
この区別は、バックポート投票、リリース投票、そして架空の合意形成の失敗による投票など、あらゆる種類の投票で行われますが、その理由はそれぞれ異なります。リリース投票では、リリースをASFの法的保護下に入れるためにこの区別が法的に義務付けられていますが、バックポート投票では、これは助言的な区別に近いです。結局のところ、正当な理由で変更に-1票を投じた場合、その人の資格は問題ではありません。もしその人の分析が正しければ、変更はバックポートされません。同様に、変更が必要な数の拘束力のある+1票を得られなくても、拘束力のない+1票がいくつかあれば、承認されるのに役立つかもしれません。
言い換えれば、バックポートプロセスの目的は、不安定化をもたらす変更がパッチリリースに入るのを防ぐことです。投票は、各変更が一定量のレビューを受けることを強制することによって、その目的を果たします。カルマは譲渡できないため、「レビュー量」は拘束力のある投票数で測定しますが、いつものように、誰でもプロセスに意見を述べ、耳を傾けてもらうことができます。
変更に対する投票者の意見は、+1、-1、+0、または-0としてエンコードされます。
「拒否権」を定義するか、定義を参照してください
拒否権（つまり-1）を行使する場合は、懸念事項欄に理由を記載し、リストディスカッションがあればそのURL/メッセージIDを含めてください。スレッドがコミット時に利用できない場合は、後でリンクを追加できます。
-0票は、変更にやや反対であることを意味します。dev@で理由を述べるか、括弧内に要約してください。ただし、合意形成の妨げにはなりません。
変更に+1票を投じることは、原則としてそれを承認することを意味するだけではありません。それは、あなたが変更を徹底的にレビューし、それが正しく、可能な限り非破壊的であると判断したことを意味します。それがリリースブランチにコミットされると、ログメッセージには、それを投票したすべての人の名前、元の作成者、コミットを実行した人の名前が含まれます。これらの人全員がバグに対して同様に責任があると見なされます。コミッターは、自分が知らないことを知っており、安易に+1票を投じないことが信頼されています。
パッチをレビューして気に入ったものの、懸念事項がある場合は、「+1（コンセプト）」と書いて、懸念事項についてリストで質問できます。一般的なアイデアは気に入っているが、パッチを注意深くレビューしていない場合は、「+0」と書くことができます。これらの票はいずれも合計にはカウントされませんが、変更をフォローしており、より多くの時間を費やす意思がある人を見つけるのに役立ちます。
非LTS（「通常」）リリースラインの場合、変更が2つの+1票を受け、拒否権がない場合に承認されます。（拘束力のある投票のみがカウントされます。上記を参照。）
LTSリリースラインの場合、変更が3つの+1票を受け、拒否権がない場合に承認されます。（拘束力のある投票のみがカウントされます。上記を参照。）
上記にかかわらず、どのリリースラインでも、コアコードではない領域（たとえば、tools/、packages/、bindings/、テストスクリプトなど）にのみ影響し、ビルドシステムに影響を与えない変更は、その領域のフルコミッターまたは部分コミッターからの1つの+1票、その他のコミッターからの少なくとも1つの+0または「コンセプト+1」票、および拒否権がない場合に入れることができます。
目標は、すべてのレビュー担当者がその領域のメンテナーと同じ量の専門知識を持っていることを要求せずに、少なくとも2組の目によって変更を確認することです。これにより、「はい、これらの変更を細部まで理解し、テストしました」と主張することを強制されることなく、一般的な健全性、正確なコメント、明らかな間違いなどをレビューできます。
変更を提案する前にSTATUS、マージの競合が発生しないことを確認するために、ブランチにマージしてみてください。競合が発生した場合は、変更をマージし、競合を解決したリリースブランチから新しい一時ブランチを作成してください。ブランチにはA.B.x-rYYYYという名前を付ける必要があります。ここで、YYYYはSTATUSファイル内の変更の最初の改訂版です。STATUSファイルに、一時ブランチの存在に関するメモをBranch: A.B.x-rYYYYまたはBranch: ^/subversion/branches/A.B.x-rYYYYヘッダー（この正確な形式を使用してください。スクリプトがそれを解析します）の形式で追加します。変更にさらなる作業が必要な場合は、これらの改訂をブランチにマージできます。この変更のエントリがSTATUSから削除されると、/branchesディレクトリの散乱を避けるために、この一時ブランチも削除する必要があります。
一時ブランチは、トランクからの変更のバックポートではない変更をA.B.xブランチに加える必要があるまれな場合にも使用されます。
別の指名がマージされるまで、マージの競合を引き起こすエントリを指名した場合は、指名にそれを書き留めてください。エントリに「Depends:」ヘッダーを配置します。これにより、毎時の「マージ競合のある指名を検出」するbuildbotジョブが緑色に保たれます。（「Depends:」ヘッダーの値は解析されません。）
tools/dist/nominate.plスクリプト（トランク内）は、新しい指名を追加するプロセスを自動化します。同じスクリプトには、指名をレビューして投票を行うプロセスを支援するREPLループもあります。tools/dist/README.backport（トランク内）を参照してください。
注意：一時ブランチに関するSTATUSへの変更（投票を含む）は、常にメインリリースブランチに保持されます。
他の人がすでに投票した指名に改訂を追加する場合は、そのエントリに「（rXのみ）」と注釈を付けて、どの部分に投票したか、どの部分に投票していないかを明確にします。次に例を示します。
* r30643, r30653, r30785
Update bash completion script.
Votes:
+1: arfrever (r30785 only), stylesen
明らかな修正については、「（rXのみ）」を言及する必要はありません。
IRCまたはその他の手段で伝達された他の人の投票をコミットする場合は、ログメッセージにそれを書き留めてください。
実際のリリースの前に、翻訳者に電子メールを送信して、.poファイルの更新をリクエストします。トランクのCOMMITTERSファイルから、次のようなコマンドを使用して、電子メールアドレスを取得します。
sed -e '/^ *Translat.*:$/,/:$/!d' -e 's/^ *[^ ]* *\([^>]*>\).*/\1/;t;d' COMMITTERS
によって生成された翻訳状況レポートを含めてください。
./tools/po/l10n-report.py
これは、ローカライズされたすべての文字列がリリース用に最終的な形式で安定した後、かつ、翻訳者が作業を行うことができるように、実際のリリースの十分に前に行う必要があります。経験則として、予定されているリリースの少なくとも1週間前、できればもっと前に通知を送信してください。新しいブランチからの最初のリリースの場合のように、多くの文字列が変更された場合は、より多くの時間を経過させてください。
さて、リリースブランチが安定し、リリースをロールする準備が整いました。ロールプロセスの詳細は、release.pyヘルパースクリプトによって自動化されています。このスクリプトを実行するには、Subversionトランクの作業コピーが必要です。release.py -hを実行して、利用可能なサブコマンドのリストを取得します。
実際にアーカイブをロールする前に、ホワイトルームロール環境をセットアップする必要があります。この環境には、一部のビルドツールの元のバージョンが含まれている必要があります。
移植性のない方法でパッチが適用されていることが多いため（たとえば、Debianのlibtoolパッチ：#291641、#320698。）、このソフトウェアのディストリビューション出荷バージョンを使用しないことが重要です。tools/dist/release-lines.yamlに示されているバージョン番号は、通常、A.B.0リリースまでの間に最新の安定したアップストリームリリースに再検討して増やす必要があります。A.B.xシリーズ内でバージョンを変更する場合は、慎重に検討する必要があります。
Autoconf、Libtool、およびSWIG：Subversion RMの任務に使用する特別なビルドツールを格納するディレクトリを選択します。たとえば/opt/svnrmなどです。3つのソフトウェアを構成、ビルド、インストールします。release.py build-envコマンドを使用します。
mkdir -p /opt/svnrm && cd /opt/svnrm && $SVN_SRC_DIR/tools/dist/release.py build-env X.Y.Z
ロールスクリプトには、次のコマンドも利用可能である必要があります。pax, xgettext, m4、およびpython -c 'import yaml'.
これらをOSパッケージからインストールします。（Debianシステムでは、apt install pax gettext m4 python-yaml subversion.)
リリースをロールする ¶:
get-deps.shがリリースブランチで機能することを確認してください。
./release.py roll X.Y.Z 1234tarballを作成する：実行release.pyが完了すると、/opt/svnrm/deploy
ディレクトリ内にtarballが作成されます。
a) tar zxvf subversion-X.Y.Z.tar.gz; cd subversion-X.Y.Z
b) ./configure
See INSTALL, section III.B for detailed instructions on
configuring/building Subversion.
If you installed Apache in some place other than the default, as
mentioned above, you will need to use the same
--prefix=/usr/local/apache2 option as used to configure Apache.
You may also want to use --enable-mod-activation, which will
automatically enable the required Subversion modules in the
Apache config file.
c) make
d) make check
e) make install (this activates mod_dav)
f) make davcheck
For this, start up Apache after having configured according to
the directions in subversion/tests/cmdline/README.
Make sure, that if you maintain a development installation of
apache, that you check the config file and update it for the
new release area where you're testing the tar-ball.
(Unless you rename the tree which gets extracted from the
tarball to match what's in httpd.conf, you will need to edit
httpd.conf)
g) make svncheck
First, start up svnserve with these args:
$ subversion/svnserve/svnserve -d -r \
`pwd`/subversion/tests/cmdline
-d tells svnserve to run as a daemon
-r tells svnserve to use the following directory as the
logical file system root directory.
After svnserve is running as a daemon 'make svncheck' should run
h) Then test that you can check out the Subversion repository
with this environment:
subversion/svn/svn co https://svn.apache.org/repos/asf/subversion/trunk
i) Verify that the perl, python, and ruby swig bindings at least compile.
If you can't do this, then have another developer verify.
(see bindings/swig/INSTALL for details)
Ensure that ./configure detected a suitable version of swig,
perl, python, and ruby. Then:
make swig-py
make check-swig-py
sudo make install-swig-py
make swig-pl
make check-swig-pl
sudo make install-swig-pl
make swig-rb
make check-swig-rb
sudo make install-swig-rb
j) Verify that the javahl bindings at least compile.
If you can't do this, then have another developer verify.
(see subversion/bindings/javahl/README for details)
Ensure that ./configure detected a suitable jdk, and then
possibly re-run with '--enable-javahl', '--with-jdk=' and
'--with-junit=':
make javahl
sudo make install-javahl
make check-javahl
k) Verify that the ctypes python bindings at least compile.
If you can't do this then have another developer verify.
(see subversion/bindings/ctypes-python/README for details)
Ensure that ./configure detected a suitable ctypesgen, and
then possibly re-run with '--with-ctypesgen':
make ctypes-python
sudo make install-ctypes-python
make check-ctypes-python
l) Verify that get-deps.sh works and does not emit any errors.
./get-deps.sh
tarballの1つまたは両方をテストする
GnuPGを使用してリリースに署名するrelease.py sign-candidates X.Y.Zrelease.pyを使用してリリースに署名する
gpg -ba subversion-X.Y.Z.tar.bz2
gpg -ba subversion-X.Y.Z.tar.gz
gpg -ba subversion-X.Y.Z.zip
これにより、次のコマンドと同等のものが実行されます対応する.ascファイルにgpg署名を追加します。
Subversion操作最終リリースを反映するsvn_version.h
release.py create-tag X.Y.Z 1234
を使用してタグを作成します。これは
を使用して行います。注：リリース候補の場合でも、常にタグを作成してください。create-tagSTATUSは、元のブランチの最終リリースを反映すると
ファイルのバージョン番号を上げます。1.0.2を実行したばかりの場合、両方のファイルに1.0.3の適切な値が含まれている必要があります。
release.py post-candidates 1.7.0
tarball、署名、チェックサムをhttps://dist.apache.org/repos/dist/dev/subversionにコミットします。このステップを自動化するrelease.pyサブコマンドがあります。
dev@リストにメールを送信します。例えば、このような内容で。
Subject: Subversion X.Y.Z up for testing/signing The X.Y.Z release artifacts are now available for testing/signing. Please get the tarballs from https://dist.apache.org/repos/dist/dev/subversion and add your signatures there. Thanks!
#svn-dev のトピックを「X.Y.Z がテスト/署名準備完了」のように調整します。
課題追跡システムを更新して、適切なバージョン/マイルストーンを設定します。新しいマイナーリリースをリリースする場合は、1.MINOR.x のバージョンを追加する必要があります。すべてのリリースで、次のリリース（つまり、1.MINOR.x+1）のバージョンを追加する必要があります。これを行う権限がない場合は、IRCで質問するか、dev@リストにメールを送信してください。
Subversionのリリースは、グローバルなコンテンツ配信ネットワーク（CDN）を通じて配信されます。（これは、2021年後半に以前のASFミラーネットワークに代わるものです。ただし、ASFリリースをミラーリングし続けることを選択する他の組織が存在する可能性があります。）
エンドユーザーがダウンロードしたソースコードパッケージの信頼性を検証できることは重要です。チェックサムはダウンロードプロセスにおける破損を検出するのに十分ですが、悪意のある個人またはミラーオペレーターが代替パッケージを配布するのを防ぐために、各ソースコードパッケージはSubversion PMCのメンバーによって暗号署名されている必要があります。これらの署名は、各コミッターのプライベートPGPキーを使用して行われ、エンドユーザーがダウンロードしたパッケージの整合性を検証できるように、リリースとともに公開されます。
Subversionのリリースが公式に公開される前に、以下のものが必要です。
tarボールの初期セットを作成するとき、リリースマネージャーは最初の署名セットも作成します。 tarボール自体は次の場所でビルドされる可能性がありますがpeople.apache.org署名がそこで生成されないことが重要です。tarボールへの署名には秘密鍵が必要であり、ASFハードウェアに秘密鍵を保存することは強く推奨されません。tarボールに署名した後（以下のプロセスを使用）、リリースマネージャーは署名を仮配布場所にアップロードし、tarボールと同じディレクトリに配置する必要があります。
PMCのメンバーだけでなく、熱心なコミュニティメンバーも、仮配布場所からtarボールをダウンロードし、テストを実行してから、署名を提供することが推奨されます。これらの署名の公開鍵は、id.apache.orgを通じてASF LDAPインスタンスに含める必要があります。（SubversionコミッターおよびPMCメンバーの現在の公開鍵のリストは、毎日LDAPから自動生成されます。）リリースマネージャーは、発表前にバージョンをテストする人がリリースの署名を完了できるように、少なくとも5日間署名を待つことが推奨されます。
tarボールへの署名とは、それについて特定のことを断言することを意味します。署名を発表するときは、リポジトリ内の適切なタグと照合してコンテンツを検証するなど、tarボールが正しいことを検証するために行った手順をメールに示してください。make checkすべてのRAレイヤーとFSバックエンドで実行することも、バインディングをビルドしてテストすることも良いアイデアです。
リリース候補を取得するには、https://dist.apache.org/repos/dist/dev/subversionの作業コピーをチェックアウトします。tarボールに対するリリースマネージャーのPGP署名を確認します。release.pyは、このステップを自動化します
release.py get-keys
release.py --target /path/to/dist/dev/subversion/wc check-sigs 1.7.0-rc4
tarボールを検証、展開、テストした後、gpgを使用して、armor化されたdetached署名を作成して署名する必要があります。.ascファイルに署名を追加するには、次のようなコマンドを使用します。
gpg -ba -o - subversion-1.7.0-rc4.tar.bz2 >> subversion-1.7.0-rc4.tar.bz2.ascrelease.pyスクリプトは、このステップを自動化できます
release.py --target /path/to/dist/dev/subversion/wc sign-candidates 1.7.0-rc4
署名を追加したら、ローカルで変更した.ascファイルをdist.apache.orgリポジトリにコミットします。
ダウンロードしてテストしたのが.tar.bz2ファイルの場合、ダウンロードして個別にテストすることなく、同じ内容の.tar.gzファイルに署名することができます。そのコツは、.bz2ファイルを展開し、gzipを使用してパックすることです。次のように。
bzip2 -cd subversion-1.7.0-rc4.tar.bz2 \
| gzip -9n > subversion-1.7.0-rc4.tar.gz
結果のファイルは、リリースマネージャーによって生成されたファイルと同一であるはずであり、したがって上記のように署名できます。ファイルが同一であることを確認するには、チェックサムまたはリリースマネージャーの署名のいずれかを使用できます。どちらもtarボールとともに提供する必要があります。
ただし、チェックサムが同一でない場合、ファイルの署名が間違っている、またはファイルが改ざんされているとは限りません。リリースマネージャーと同じgzipバージョンを持っていないだけである可能性も十分にあります。
tarボールが作成され、すべての署名が作成および検証されたら、リリースを公開する準備が完了します。このセクションでは、Subversionリリースを公開するために必要な手順の概要を説明します。
Subversionのアーティファクトは、グローバルなコンテンツ配信ネットワーク（CDN）を通じて配信されます。ソースコードのダウンロードページは、適切なダウンロードリンクを選択する際にユーザーを自動的に支援します。通常、プロジェクトの配布ディレクトリには、サポートされているリリースラインの最新の安定リリースのみをホストしますが、以前のすべてのSubversionリリースはアーカイブで利用できます。
CDNにリリースをアップロードするには
release.py move-to-dist 1.7.0これにより、tarボール、署名、チェックサムが^/dev/subversionから^/release/subversionに移動します。コンテンツ配信ネットワーク（CDN）が新しいリリースをピックアップするのに約15分かかります。アーカイブも自動的にリリースをピックアップします。実行してもmove-to-dist署名ファイルは移動されますが、コミッターは引き続き新しい署名を^/release/subversionにコミットできます。ただし、これらの署名がCDNに表示されるまでに最大15分かかります。このような署名は、コミットされてから15分が経過しない限り、リリース発表に含めることはできません。
この時点で、リリースは一般に公開されている可能性がありますが、CDNがピックアップするまで発表を控えるのが賢明です。CDNが同期するのに十分な時間が経過した後、リリースマネージャーは発表を送信し、以下で説明するようにSubversion Webサイトへの変更を公開します。
また、古いリリースを削除するのに良いタイミングです。^/release/subversion各サポートされているリリースラインの最新リリースのみがそのディレクトリにある必要があります。少なくとも24時間利用可能になっているリリースは^/release/subversionアーカイブで引き続き利用できます。古いリリースは次を使用してクリーンアップできます。
release.py clean-dist
reporter.apache.orgに新しいリリースのバージョン番号を送信します。次のコマンド
curl -u USERNAME "https://reporter.apache.org/addrelease.py?date=`date +%s`&committee=subversion&version=VERSION&xdate=`date +%F`"はリリースを追加します。おそらくrelease.pyに追加する必要があります。
以下の手順では、公開されたWebサイトを直接更新するように指示していますが、^/subversion/site/stagingで変更を準備できます。その場合
からキャッチアップマージを実行します。^/subversion/site/publish.
への変更をコミットします。^/subversion/site/stagingそして、https://subversion-staging.apache.orgで結果を確認します。
公開の準備ができたら、変更を^/subversion/site/publishにマージし直します（マージの準備ができていないステージングでの他の変更がある場合に備えて、マージを確認します）。
プレリリース（alpha/beta/rc）を含むすべてのリリースについて
編集^/subversion/site/publish/download.html最新のリリースを記録します。release.py write-downloadsを使用して、テーブルを生成します。これが安定リリースである場合は、次のものを更新します。[version]または[supported]eztマクロ定義（例：[define version]1.7.0[end]）; これがプレリリースである場合は、<div id="pre-releases">のコメントを解除します。これがプレリリースを無効にする1.x.0リリースである場合は、コメントを戻します。
新しいニュースアイテムを^/subversion/site/publish/news.htmlに追加して、リリースを発表します。同じアイテムを^/subversion/site/publish/index.htmlのニュースリストに追加し、そのページから最も古いニュースアイテムを削除します。release.py write-newsを使用して、カスタマイズする必要があるテンプレートニュースアイテムを生成します。ニュースアイテムには、発表メールへのリンクを含める必要があるセクションがあります。今のところ、コメントアウトされており、リンクは後で追加されます。リリース日より前にテンプレートを生成した場合は、日付が正しいことを確認してください。
さらに、これが安定リリースX.Y.Z（alpha/beta/rcではない）である場合
次の場所に新しいリリースをリストします。^/subversion/site/publish/doap.rdf
サポートされている各マイナーリリースに対して、<created>と<revision>が現在のリリース日とパッチリリース番号に更新された<release>セクションがあるはずです。ファイル内の他のものを変更しないでください（特に、<Project>の下の<created>は、Subversionプロジェクトが作成された日付です）。
次の場所に新しいリリースをリストします。^/subversion/site/publish/docs/release-notes/release-history.html
さらに、これが新しいマイナーリリースX.Y.0である場合
^/subversion/site/publish/docs/release-notes/index.htmlの「サポートされているバージョン」セクションでコミュニティリリースのサポートレベルを更新します
更新supported_release_linesをrelease.pyで更新し、必要に応じて古い行を削除します。
「ドラフト」警告を^/subversion/site/publish/docs/release-notes/X.Y.html
から削除します^/site/publish/docs/api/X.Yは、元のブランチの^/site/publish/docs/javahl/X.Yのバージョン付きドキュメントスナップショットを作成または更新し、それらのディレクトリの兄弟であるlatestのシンボリックリンクが、常に最新のリリースシリーズのディレクトリを指していることを確認します。
例
VER=1.12 DOCS_WC=~/src/svn/site/staging/docs TAG_BUILD_DIR=~/src/svn/tags/$VER.x/obj-dir cd $TAG_BUILD_DIR make doc cp -a doc/doxygen/html $DOCS_WC/api/$VER cp -a doc/javadoc $DOCS_WC/javahl/$VER for D in $DOCS_WC/api $DOCS_WC/javahl; do svn add $D/$VER rm $D/latest && ln -s $VER $D/latest done svn ci -m "In 'staging': Add $VER API docs." $DOCS_WC/api $DOCS_WC/javahl
インデックスページdocs/index.html#apiのAPIドキュメントへのリンクを更新します。
リリース日に「publish」への変更をコミットします（または「staging」から「publish」にマージします）。
新しいマイナーリリース（番号1.x.0）にはプレスリリースが添付される場合があります。見込みのあるプレスリリースのすべての詳細は、private@リストで、press@a.oと連携して処理されます。
経験則として、ソークの開始時にprivate@ / press@でスレッドを開始してください。press@への事前警告は、短すぎるよりも長すぎる方が良いです。
以前のものを参考に、リリース発表を作成します。発表にはURLとチェックサムを含めることを忘れないでください！release.py write-announcementサブコマンドは、特定の状況に合わせてカスタマイズできるテンプレート発表を作成します。リリースでセキュリティ問題が修正された場合は、--securityフラグを渡して、出力で正しい件名、Cc、および説明を生成します。
このリリースでコミュニティのサポートレベルが変更されている場合は、発表を生成する前に、release.pyでrecommended_release変数を必ず更新してください。
発表は、あなたの @apache.org のメールアドレスから送信してください。（announce@ 宛のメールは、他のアドレスから送信された場合、バウンスされます。最良の結果を得るには、コミッターメールページの指示に従い、公式メールリレー経由でメッセージを送信してください。）メールソフトがURLを複数行に折り返さないようにしてください。
注意: リリース発表のリンクが有効であることを確認するため、リリース発表前にウェブサイトを更新します。リリース発表後、リリース発表メールへのリンクがウェブサイトに追加されます。
リリース発表が投稿される announce@ メーリングリストは2つあります。Subversionプロジェクトの announce@subversion.apache.org リストと、ASF全体の announce@apache.org リストです。ASF全体の announce@ リストへのメッセージは拒否される可能性があります。これにより、次のような件名でモデレーション通知が生成されます。Returned post for announce@apache.org。メーリングリストソフトウェアにメッセージを拒否させたモデレーターが、拒否メッセージに署名を忘れることがあり、拒否が匿名になったり、拒否の理由が無効である可能性があります。そうであっても、冷静さを保ち、拒否メッセージを dev@ メーリングリストに転送して、プロジェクトで何か対処する必要があるかどうかを議論してください。（必要であれば、announce@ メーリングリストのモデレーターには、announce-owner@ ハンドルを介して連絡できます。）
以下のような、Subversion関連のさまざまなIRCチャンネルのトピックを更新してください。#svnは、元のブランチの#svn-devlibera.chat で。
これが X.Y.0 リリースの場合、サポートステータスが変更されたブランチのSTATUSファイルの最上部にあるコミュニティサポートレベルを更新します。通常これはX.Y.x/STATUS, X.$((Y-1)).x/STATUSであり、新しいリリースがLTSリリースである場合は、サポートされている最も古いLTSブランチのSTATUSファイルも同様です。
更新^/subversion/site/publish/news.htmlは、元のブランチの^/subversion/site/publish/index.htmlリリース発表メールへのリンクのコメントを外し、追加します。
これで、リリース管理者は $favorite_beverage を楽しむ時間です。
新しいリリースブランチは、新しいメジャーおよびマイナーリリースごとに作成されます。たとえば、バージョン 2.0.0 またはバージョン 1.3.0 のリリースを準備するときに新しいリリースブランチが作成されます。ただし、1.3.1（パッチバージョンインクリメント）のリリースを準備するときは、1.3.0 のときに作成されたリリースブランチが使用されます。
パッチリリースを準備している場合は、作成するリリースブランチはありません。現在のマイナーバージョンシリーズのリリースブランチで中断したところから再開するだけです。
新しいリリースブランチを作成する必要があるタイミングは、曖昧な場合がほとんどです。一般的に、新しいマイナーバージョンを6か月ごとにリリースするという緩やかなスケジュールがあります。したがって、前のマイナーリリースから約4か月後が、ブランチを提案し始めるのに適した時期です。ただし、これは開発されている機能によって柔軟に対応できることに注意してください。
ロードマップを確認してください。ブランチング前に未解決の項目を処理する必要がありますか？
現行の安定ブランチの STATUS ファイルで、未解決の -0 および -1 投票を確認してください。新しいブランチに含まれる予定のコードに反対がありましたか？ （たとえそうであっても、それはブランチングを妨げるべきではありませんが、リリースブランチをロールする前に問題を解決するために議論を開始する必要があります。）
ツリー全体の機械的な変更を行います。（機械的でない変更は、レビューできるように、より早い段階で行われている必要があります。）これにより、後でマージが容易になります。例として、末尾の空白を削除する、エラーリークを修正する、Cヘッダーの不変性を修正する（別のケース）、コードの検索と置換などがあります。（これは、静的解析などの定期的なハウスキーピングタスクを実行するのにも良い時期です。）
新しいAPIおよび変更されたAPIについて、設計とスタイル（例：Doxygenマークアップ、ドキュメント化されていないパラメータ、非推奨、公開/非公開ステータスなど）を確認してください。
abi-laboratory.pro Subversionが役立つ場合があります。
現行のマイナーリリースに対して互換性テストを実行します。
新しいリリースブランチを作成することに同意したら、リリース管理者は次のいずれかの手順で作成します（A.Bを準備中のバージョン（例：1.3または2.0）に置き換えてください）。
リリースブランチを作成する作業のほとんどは、tools/dist/release.py で自動化できます。
一時的なチェックアウトを作成する空のディレクトリで実行してください。
release.py --verbose create-release-branch A.B.0
まだ行っていない場合は、プロジェクトWebサイトのリリースノートテンプレートを作成します。
release.py --verbose write-release-notes A.B.0 > .../docs/release-notes/A.B.html svn add .../docs/release-notes/A.B.html svn ci -m "Add release notes template." .../docs/release-notes/A.B.html
このセクションのほとんどの手順は、tools/dist/release.py で自動化できます（上記参照）。ただし、リリース管理者が手動で行う場合に備えて、ここに文書化されています。
サーバー側のコピーを使用して、新しいリリースブランチを作成します。
svn cp ^/subversion/trunk \
^/subversion/branches/A.B.x \
-m "Create the A.B.x release branch."
編集subversion/include/svn_version.htrunkで、バージョン番号をインクリメントします。これらの変更はまだコミットしないでください。
trunkのバージョン番号は常に、ブランチを作成した直後のメジャー/マイナーバージョン（例：2.0.xブランチの場合は2.1.0、1.3.xブランチの場合は1.4.0）を反映します。
編集subversion/bindings/javahl/src/org/apache/subversion/javahl/NativeResources.javatrunkで、インクリメントします。SVN_VER_MINOR。これらの変更はまだコミットしないでください。
編集subversion/tests/cmdline/svntest/main.pytrunkで、インクリメントします。SVN_VER_MINOR。これらの変更はまだコミットしないでください。
編集トランクからのtrunkで、今後のリリース用にまだない場合は新しいセクションを導入し、将来作成される次のマイナーリリース用の新しいセクションも導入します。各セクションは次で始まります。
Version A.B.0
(?? ??? 20XX, from /branches/A.B.x)
https://svn.apache.org/repos/asf/subversion/tags/A.B.0
リリース日は今のところ空白のままにしておきます。これは、ロール時間までこのままです。
これらの変更を、次のようなログメッセージでコミットします。
Increment the trunk version number to A.$((B+1)), and introduce a new CHANGES
section, following the creation of the A.B.x release branch.
* subversion/include/svn_version.h,
subversion/bindings/javahl/src/org/apache/subversion/javahl/NativeResources.java,
subversion/tests/cmdline/svntest/main.py
(SVN_VER_MINOR): Increment to $((B+1)).
* CHANGES: New section for A.$((B+1)).0.
新しいSTATUSファイルをリリースブランチに作成します。
すべてのbuildbotビルダーが新しいリリースブランチをビルドしていることを確認します。
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/subversion.conf の MINOR_LINES リストに A.B を追加します。
テンプレートのリリースノートドキュメントを作成します。site/publish/docs/release-notes/A.B.html
適切なアクセス権を持つ人に、A.B.x ブランチをバックポートマージボットに追加するように依頼してください。
リリースが通常かLTSかを決定し、その決定をlts_release_linesに記録します。tools/dist/release-lines.yamlrelease.py 用。
バックポートマージボットは、svn-qavm1マシンで、svnsvnローカルユーザーアカウントで、svn-roleSubversionアカウント名を使用してコミットを行いながら、毎晩実行されます。
この構成では、現在、マシンの管理者アクセス権を持つ人が、ブランチのセットへの変更を管理する必要があります。
ボットは、〜svnsvn/src/svn/A.B.x にWCディレクトリが存在する各ブランチA.B.xで承認されたバックポートをマージします。〜svnsvn/src/svn/A.B.x .
そこのチェックアウトは、（例えば sudo を使用して）次のようにsvnsvnユーザーとして実行することで作成されました。
svn checkout --depth=empty https://svn-master.apache.org/repos/asf/subversion/branches ~svnsvn/src/svn svn up ~svnsvn/src/svn/A.B.x # for each supported branch
リポジトリURLはsvn-master.a.oです。バックポートマージャーがsvn ci && svn upをループで実行し、svn upが、コミットしたばかりのリビジョンに更新すると想定しているためです。ミラーから更新する場合、これは保証されていません（およびsvn.a.oがミラーを指している可能性があります）。buildbotスレーブも、同じ理由でこれを行います。
各ブランチは、WCルートのサブディレクトリにあります。新しいブランチを追加するには、ソースツリーにsvn up:
sudo -H -u svnsvn svn up ~svnsvn/src/svn/A.B.x
サポートされなくなったブランチを削除するには、svn up -r0:
sudo -H -u svnsvn svn up -r0 ~svnsvn/src/svn/Z.Z.x
を使用します。machines/svn-qavm1/および Subversion PMC のプライベートリポジトリにあります。また、machines/.
リリースブランチが作成されたら、そこでは決して開発が行われません。許可される変更は、次のようなさまざまな簿記ファイルに対する変更のみです。STATUSや、trunkからマージされた変更です。まれに、リリースブランチに固有の問題に対処するために（たとえば、trunkに影響を与えないバグを修正するために）、A.B.xブランチからフィーチャーブランチが作成される場合があります。
trunkからの変更のマージを承認または拒否するために使用されるプロトコルは、すべてのSubversion開発者にとって関心のあるものであり、リリース安定化セクションに文書化されています。
ファイルは、プロジェクトの変更ログファイルです。リリース前に、前回のリリース以降のすべての変更をリストするように最新の状態にする必要があります。トランクからのファイルは、プロジェクトの変更ログファイルです。リリース前に、前回のリリース以降のすべての変更をリストするように最新の状態にする必要があります。
以下に、手動プロセスについて説明します。部分的な自動化については、
release.py write-changelog
パッチリリースの場合、これは非常に簡単です。前回の「ゴールデン」リビジョン以降のブランチのコミットログを調べて、興味深いマージをすべてメモするだけです。マイナーおよびメジャーリリースの場合、これはより複雑です。前回のリリースブランチがフォークされてからのtrunkのコミットログを調べて、すべての変更をメモする必要があります。手順は同じですが、以前のリリースブランチにすでにバックポートされ、そこからリリースされた変更セットをフィルタリングする必要があるため、はるかに長く、やや複雑になります。
常にトランクからのは、trunkで編集し、必要に応じてリリースブランチにマージする必要があります。すべてのリリースのすべての変更が、trunkのトランクからのファイルに記録されていることが非常に重要です。将来の参照のためと、将来のリリースブランチに以前のすべての変更ログの合計が含まれるようにするためです。
各変更の箇条書きは簡潔に、できれば1行以内にしてください。場合によっては困難な場合がありますが、ドキュメント全体の読みやすさが向上します。自問自答してください。説明に1行以上かかる場合、詳細になりすぎているのではないか？
実行svn log --stop-on-copy ^/subversion/branches/A.B.xこれにより、A.B.xブランチに対して行われたすべての変更（A.B.xブランチへのバックポートを含む）がわかります。次に、以前のメジャー/マイナーブランチのマイクロリリースですでにリリースされている変更のログを削除する必要があります。実行svn log -q --stop-on-copy以前のリリースブランチで実行し、revnumを解析して、プライマリログ出力から削除するスクリプトを作成します。（以前はKarlとBenはemacsマクロを使用していましたが、より汎用的なスクリプトを作成することを提案しています。）（更新：最近は、svn mergeinfo --show-revs eligible関連するリビジョンのセットを取得するのが簡単になります。マイナーブランチをソースとして、以前のマイナーブランチをターゲットとして使用します。）
ログを古い順に読んで、ポイントをまとめます。重要なのは、どのレベルの詳細で記述するかを知ることです。細かなコミットすべてを言及する必要はありませんが、あまりにも一般的すぎるのも良くありません。新しいセクションを開始する前に、数ページトランクからのファイルを読み通して、フィルターレベルを設定し、一貫性を保ちます。
リリース安定化の一環として、トランクからのバグ修正がリリースブランチに移植されるにつれて更新する必要があります。通常、リビジョンまたはリビジョングループ（つまり、STATUSのアイテム）をリリースブランチにマージする場合は、上記と同じガイドラインに従って、トランクからのトランクにもアイテムを追加する必要があります。このリストは、パッチリリースが行われるときにリリースブランチにマージされます。
実際には、修正がリリースブランチにバックポートされるたびに、CHANGESが更新されるわけではありません。通常、リリース管理者はパッチリリースを行う最初のステップの1つとしてCHANGESを更新します。
CHANGESに記載する必要があるバックポートのリストを取得する便利な方法は、Subversion Webサイトの次のパッチリリースで予定されていることを設定するのと同じツールを使用することです。これは、upcoming.pyスクリプトで、https://svn.apache.org/repos/asf/subversion/site/toolsにあります。現在の作業ディレクトリがマイナーブランチのワーキングコピーのルートであるときに実行します。