Author: mumumu Date: Thu Oct 11 16:15:45 2007 New Revision: 1242 Log: - "Mechanics of Release Branches" translated.
Modified: trunk/ja/ch07.xml Modified: trunk/ja/ch07.xml ============================================================================== --- trunk/ja/ch07.xml (original) +++ trunk/ja/ch07.xml Thu Oct 11 16:15:45 2007 @@ -1074,8 +1074,9 @@ <!-- ======================== subsection ============================== --> <sect2 id="release-branch-mechanics"> -<title>Mechanics of Release Branches</title> +<title>リリースブランチのしくみ</title> +<!-- <para>The exact mechanics of creating a release branch depend on your version control system, of course, but the general concepts are the same in most systems. A branch usually sprouts from another branch or @@ -1083,24 +1084,49 @@ development goes on, unfettered by release constraints. The first release branch, the one leading to the "1.0" release, sprouts off the trunk. In CVS, the branch command would be something like this</para> +--> + +<para> + リリースブランチを作成する正確な手順は、 + 利用しているバージョン管理システムに依存しますが、 + ほとんどのシステムでは、一般的な概念は勿論同じです。 + ブランチは通常別のブランチか、trunk（幹）から派生します。 + 伝統的に、trunk では本線の開発が進んでおり、リリースの制限を受けません。 + リリース "1.0" 用のはじめてのリリースブランチは trunk から派生します。 + CVS では、ブランチを作成するコマンドは次のようなものです。 +</para> <screen> $ cd trunk-working-copy $ cvs tag -b RELEASE_1_0_X </screen> +<!-- <para>or in Subversion, like this:</para> +--> + +<para>Subversionでは、次のようになります</para> <screen> $ svn copy http://.../repos/trunk http://.../repos/branches/1.0.x </screen> +<!-- <para>(All these examples assume a three-component release numbering system. While I can't show the exact commands for every version control system, I'll give examples in CVS and Subversion and hope that the corresponding commands in other systems can be deduced from those two.)</para> +--> + +<para> + （これらの例はすべて、３つの数でリリース番号を付けるやり方を想定したものです。 + それぞれのバージョン管理システムで使われる正確なコマンドを示すことはできませんが、 + CVS と Subversion の例を示すことで、 + 他のシステムで対応するコマンドが予測できればいいなと思っています。） +</para> +<!-- <para>Notice that we created branch "1.0.x" (with a literal "x") instead of "1.0.0". This is because the same minor line—i.e., the same branch—will be used for all the micro releases in that @@ -1111,18 +1137,32 @@ concerned just with the interaction between the version control system and the release process. When the release branch is stabilized and ready, it is time to tag a snapshot from the branch:</para> +--> + +<para> + "1.0.0" ではなく、 + (文字通り "x" という文字を使って）"1.0.x" ブランチを作成したことに注意してください。 + これは同じマイナーライン — つまり、同じブランチということです — + が全てのマイクロリリースで使われるということです。 + リリースのためにブランチを安定させる実際の過程については、 + <phrase output="printed">この章の後半の</phrase> <xref linkend="stabilizing-a-release"/> で説明しています。 + ここでは、バージョン管理システムとリリースプロセスの関係にだけ注意を払うことにします。 + ブランチが安定し、リリースの準備ができたら、 + 次のようにしてブランチのスナップショットにタグを打つときです。 +</para> <screen> $ cd RELEASE_1_0_X-working-copy $ cvs tag RELEASE_1_0_0 </screen> -<para>or</para> +<para>CVS では上のようにし、Subversion では以下のようにします。</para> <screen> $ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.0 </screen> +<!-- <para>That tag now represents the exact state of the project's source tree in the 1.0.0 release (this is useful in case anyone ever needs to get an old version after the packaged distributions and binaries have @@ -1131,18 +1171,33 @@ 1.0.1. Lather, rinse, repeat for 1.0.2, and so on. When it's time to start thinking about a 1.1.x release, make a new branch from trunk:</para> +--> + +<para> + このタグは 1.0.0 がリリースされた時点の、 + プロジェクトのソースツリーの正確な状態を表しています。 + （これはパッケージ化された配布物やバイナリが〜された後で、 + 誰かが古いバージョンを取得したい場合に役に立ちます。） + 同じリリースラインでの次のマイクロリリースは、 + 同じく 1.0.x ブランチ上で準備され、リリースの準備が出来次第、 + 1.0.1 のタグが打たれます。 + 1.0.2 に向けて繰り返しブランチを綺麗にしていきましょう。 + 1.1.x リリースラインにについて考え始める時期が来たら、 + 次のようにして新しいブランチを trunk から作ります。 +</para> <screen> $ cd trunk-working-copy $ cvs tag -b RELEASE_1_1_X </screen> -<para>or</para> +<para>CVS では上のようにし、Subversion では以下のようにします。</para> <screen> $ svn copy http://.../repos/trunk http://.../repos/branches/1.1.x </screen> +<!-- <para>Maintenance can continue in parallel along both 1.0.x and 1.1.x, and releases can be made independently from both lines. In fact, it is not unusual to publish near-simultaneous releases from two @@ -1152,9 +1207,24 @@ adventurous people usually take the most recent release on the highest line, to make sure they're getting the latest features, even at the risk of greater instability.</para> +--> + +<para> + メンテナンスは 1.0.x と 1.1.x ラインに対して並行して続けられ、 + リリースは両方のラインから独立して行えます。 + 実際、ふたつの異なったラインからほとんど同時にリリースが行われることも珍しくありません。 + 古いラインからのリリースは、 + 一気に（たとえば）1.1 へバージョンアップしたいときは、 + 必ず周到な準備をしたいと望む保守的なサイト管理者にお薦めです。 + 一方で大胆なユーザーは通常、 + 不安定なバージョンであるというリスクを負ってでも、 + 自分達が最新の機能を使っていることを確認するために、 + より新しいラインの最新のリリースを採用します。 +</para> </sect2> +<!-- <para>This is not the only release branch strategy, of course. In some circumstances it may not even be the best, though it's worked out pretty well for projects I've been involved in. Use any strategy that @@ -1163,12 +1233,26 @@ development, and to give the project a physical entity around which to organize its release process. That process is described in detail in the next section.</para> +--> + +<para> + これは勿論、リリースブランチに限った戦略ではありません。 + 自分が参加していたプロジェクトではとてもうまくいっていたのに、 + ある状況下ではうまくいかないことさえあるかもしれません。 + うまくいきそうな戦略を使ってください。 + しかし、重要な以下の点を覚えておきましょう。 + つまり、リリースブランチの目的は、 + 日々の開発作業によって生まれる変化からリリース作業を分離することと、 + リリースプロセスを組織的に行うために、 + 物理的な作業スペースをプロジェクトに与えることです。 + このプロセスは次の節で説明します。 +</para> </sect1> <!-- ======================== SECTION ============================== --> <sect1 id="stabilizing-a-release"> -<title>Stabilizing a Release</title> +<title>リリースを安定させる</title> <para><firstterm>Stabilization</firstterm> is the process of getting a release branch into a releasable state; that is, of deciding which _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
