Author: mumumu
Date: Sat Oct 13 17:51:13 2007
New Revision: 1254
Log:
- "Stabilizing release" translated.
Modified:
trunk/ja/ch07.xml
Modified: trunk/ja/ch07.xml
==============================================================================
--- trunk/ja/ch07.xml (original)
+++ trunk/ja/ch07.xml Sat Oct 13 17:51:13 2007
@@ -295,7 +295,7 @@
些細な話題なのに最も古くからあちこちで議論されてきた（<phrase output="printed"><xref
linkend="communications"/> の </phrase> <xref linkend="bikeshed"/>
を参照してください）もののひとつですが、
近い将来、唯一の完全な標準に落ち着く気配はありません。
しかし、<emphasis>一貫していること</emphasis> という普遍的に受け入れられた原則に基づいて、
- 優れた戦略がいくつか現れてきています。
+ 優れた戦略がいくつか出てきています。
番号の付け方を選び、それを文書化し、守るようにしましょう。
番号の付け方をはっきりさせれば、ユーザーはあなたに感謝することでしょう。
</para>
@@ -316,7 +316,6 @@
読者に前提となる知識が殆どないことを想定しています。
主に参考資料として読まれることを意図していますが、
あなたが既にこうした規約に馴染んでいるのなら、飛ばして読んでも構いません。
-
</para>
<para>リリース番号はドットで区切られた数字の集まりです。</para>
@@ -384,9 +383,9 @@
同じバージョン番号ながら、
こうした識別子がつかないものが将来リリースされることを示しています。
よって、"2.3.0 (Alpha)" は結局 "2.3.0" になります。
- このような、複数の最終リリースの候補となるものを一行であらわすために、
+ このように、複数の最終リリースの候補となるものを一行であらわすために、
識別子そのものが メタ識別子 を持つことができます。
- たとえば、一般の人が利用できるようになるまでの順番で、
+ 例として、一般の人が利用できるようになるまでの順番で、
一連のリリースを以下に示します。
</para>
@@ -492,7 +491,7 @@
-->
<para>
- リリース番号を付ける一貫したポリシーがあれば、
+ リリース番号を付ける一貫した決まりがあれば、
ユーザーは同じソフトウェアのふたつのリリース番号を見て、
数字だけでふたつの重要な違いを区別できるようになります。
3つの数字からなる典型的なリリース番号では、
@@ -543,7 +542,7 @@
3番目のマイクロ番号と同じ意味で用いているプロジェクトもあります。）
最後の数字を <firstterm>ビルド番号</firstterm> として用いるプロジェクトもあります。
ビルド番号はソフトウェアがビルドされるたびにひとつ増えていき、
- ビルド以外の変更がないことを表しています。
+ ビルド以外の変更がないことをあらわしています。
ビルド番号はバグレポートを特定のビルド番号に結びつけるのに役立ちますし、
バイナリパッケージを通常配布しているプロジェクトで、恐らくもっとも役に立つでしょう。
</para>
@@ -679,13 +678,13 @@
たとえば、あなたのプロジェクトがクライアント/サーバ アプリケーションを作っているとすると、
"後方互換性" とは、サーバを 2.6.0 にアップグレードしても
既にあるバージョン 2.5.4 のクライアントが以前と異なる振舞い（もちろんバグを直した場合は別です）をしたり、
- 動かなくなる機能があったりしてはいけないということです。
- 一方、サーバを 2.6.0 にアップグレードするとともに、クライアントも2.6.0にすると、
+ 動かなくなる機能があってはいけないということです。
+ 一方、サーバを 2.6.0 にアップグレードすると同時に、クライアントも2.6.0にすると、
<emphasis>新しい</emphasis> 機能がクライアントで使えるようになるかもしれませんが、
- 2.5.4で使えていたクライアントの機能は 2.6.0 でどのように扱われるかわかりません。
+ 2.5.4で使えていたクライアントの機能は 2.6.0 でどう扱われるかわかりません。
こういうことが起こると、このクライアントのアップグレードには 前方互換性が <emphasis>ない</emphasis> ことになります。
つまり、クライアントを 2.5.4 にダウングレードしても、
- 2.6.0で使えていた全ての機能は使えないということになります。
+ 2.6.0 で使えていた全ての機能は使えないということになります。
なぜなら、2.6.0 の機能には新機能が含まれているからです。
</para>
@@ -736,8 +735,9 @@
なぜなら、マイナー番号をまたがるとダウングレードできる必要はないからです。
あなたのプロジェクトが他のプログラムで使われているライブラリを配布しているとすると、
その API も互換性の問題が起こる領域に入ります。
- 新しいバージョンに古いバージョンを置き換える形でアップグレードしても安全かどうか、詳しいユーザーがわかるように、
- ソース、バイナリレベルでの互換性に関するルールを詳しく説明しておかなければなりません。
+ 新しいバージョンに古いバージョンを置き換える形でアップグレードしても安全かどうか、
+ 詳しいユーザーがわかるように、
+ ソース、バイナリレベルでの互換性に関するルールを詳しく説明しておかなければいけません。
詳しいユーザーは、バージョン番号をみれば互換性があるかどうかがすぐにわかるでしょう。
</para>
@@ -793,12 +793,12 @@
リリースポリシーではこのことを明示的に宣言しておくべきです）
開発の初期段階にあるプロジェクトは、 バージョン 0.1, 0.2, 0.3 といった順で、
1.0 の準備ができるまでリリースを行うことができますし、
- リリース間の差異は適宜大きくすることができます。
- バージョン 1.0以前は、マイクロ番号を使うかどうかは任意です。
+ リリース間の違いを適宜大きくすることができます。
+ バージョン 1.0 以前は、マイクロ番号を使うかどうかは任意です。
プロジェクトの性質とリリース間の差異によっては、
0.1.0, 0.1.1 といった番号があれば便利かもしれませんし、そうでないかもしれません。
バージョン 1.0 以前のリリース番号のルールはかなりルーズです。
- これは互換性に関する制約をきつくすると初期段階の開発を著しく妨げることや、
+ これは互換性に関する制約をきつくすると初期段階の開発を著しく妨げることと、
早くから使っている人はどちらにせよ寛大な傾向にあることが主な理由です。
</para>
@@ -812,10 +812,11 @@
-->
<para>
- こうした制約は、ここで説明した３つの数字を使った番号の付け方にだけ当てはまります。
- あなたのプロジェクトでは、３つの番号を使って、
+ こうした制約は、３つの数字を使った番号の付け方にだけ当てはまります。
+ あなたのプロジェクトでは、３つの数字を使って、
これとは違った番号の付け方を簡単に思い付くでしょう。
- もしくは、細かい粒度は必要ないので、代わりに２つの番号を使おうと決めることもできるでしょう。
+ もしくは、細かい粒度は必要ないので、
+ 代わりに２つの番号を使おうと決めることもできるでしょう。
重要なのは、こういうことは早めに決めておいて、
それぞれの数字が意味するところを正確に皆に知らせ、それを守ることです。
</para>
@@ -836,14 +837,15 @@
-->
<para>
- プロジェクトによっては、マイナー番号の偶数/奇数をソフトウェアの安定度を示すのに使うことがあります。
+ プロジェクトによっては、
+ マイナー番号の 偶数/奇数 をソフトウェアの安定度を示すために使うことがあります。
つまり、偶数は安定版で、奇数は不安定版ということです。
これはマイナー番号にのみ当てはまることで、
メジャー番号とマイクロ番号には当てはまりません。
マイクロ番号をひとつ増やすことは、
バグフィックスが行われた（新機能はない）ことを示しますし、
メジャー番号をひとつ増やすことは、
- 大きな変更が行われたか、新機能が揃っていることを表しています。
+ 大きな変更が行われたか、新機能が揃っていることをあらわしています。
</para>
<!--
@@ -900,7 +902,8 @@
大きな害はありません。
奇数/偶数に意味を持たせる仕組みは、
リリースサイクルがとても長いプロジェクトでもっとも有効でしょうし、
- プロジェクトの性質上、新機能よりも安定性に重きを置く保守的なユーザの割合が高いところでも有効です。
+ プロジェクトの性質上、
+ 新機能よりも安定性に重きを置く保守的なユーザの割合が高いところでも有効です。
この仕組みが、新機能を大胆にテストする唯一の方法ではありません。
<phrase output="printed">この章の後半の</phrase> <xref
linkend="stabilizing-a-release"/> でも説明していますが、
潜在的に不安定なコードをリリースするもっと一般的な方法は、
@@ -956,9 +959,9 @@
-->
<para>
- では、プロジェクトはどうやって正式なリリース作業を行うべきなのでしょうか。
+ では、プロジェクトはソフトウェアをどうやって正式にリリースすべきなのでしょうか。
ある時点のソースツリーのスナップショットを取得してパッケージにまとめ、
- 世界中にたとえばバージョン "3.5.0" として配布すべきなのでしょうか。
+ たとえばバージョン "3.5.0" として世界中に配布すべきなのでしょうか。
常識的からいって答えはNOです。第一、開発ツリー全体が綺麗になっていて、
リリースの準備ができている瞬間なんて多分ありません。
開発を始めた新機能のコードが、様々な完成度でそこらじゅうに転がっているでしょう。
@@ -993,14 +996,13 @@
そのとき進行している開発を妨げてしまいがちです。
たとえば、現在のスナップショットを仮に "3.5.0" とし、
次のスナップショットが "3.5.1" になるとして、
- 次のスナップショットにはリリース 3.5.0 で見つかったバグの修正が殆ど含まれているとしましょう。
+ "3.5.1" にはリリース 3.5.0 で見つかったバグの修正が殆ど含まれているとしましょう。
しかし、この両方のスナップショットが同じツリーにあると、
開発者はこのふたつがリリースされている間何をすべきでしょうか？
互換性に関するガイドラインがあるため、新機能を追加することはできません。
しかし、開発者全員が 3.5.0 のコードに入っているバグを熱心に修正するとは限りません。
- 開発者の中には新機能を完成させようとしている人もいます。
- プロジェクトのリリースプロセスが、
- ツリーを不自然な休止状態にする必要があるからという理由だけで、
+ 新機能を完成させようとしている開発者もいます。
+ リリース作業がソースツリーを不自然な休止状態にする必要があるという理由だけで、
自分が興味がないことに取り組むか、
ぼけっとしているかを選ばねばならなくなったら、開発者は怒ってしまうでしょう。
</para>
@@ -1074,7 +1076,7 @@
<!-- ======================== subsection ============================== -->
<sect2 id="release-branch-mechanics">
-<title>リリースブランチの作り方</title>
+<title>リリースブランチの使い方</title>
<!--
<para>The exact mechanics of creating a release branch depend on your
@@ -1087,13 +1089,13 @@
-->
<para>
- リリースブランチを作成する正確な手順は、
+ リリースブランチを作る正確な手順は、
利用しているバージョン管理システムに依存しますが、
ほとんどのシステムでは、一般的な概念は勿論同じです。
ブランチは通常別のブランチか、trunk（幹）から派生します。
伝統的に、trunk では本線の開発が進んでおり、リリースの制限を受けません。
リリース "1.0" 用のはじめてのリリースブランチは trunk から派生します。
- CVS では、ブランチを作成するコマンドは次のようなものです。
+ CVS では、ブランチを作成するコマンドは次のようになります。
</para>
<screen>
@@ -1105,7 +1107,7 @@
<para>or in Subversion, like this:</para>
-->
-<para>Subversionでは、次のようになります。</para>
+<para>Subversionでは、次のようにします。</para>
<screen>
$ svn copy http://.../repos/trunk http://.../repos/branches/1.0.x
@@ -1157,7 +1159,7 @@
$ cvs tag RELEASE_1_0_0
</screen>
-<para>Subversion では下のようにします。</para>
+<para>Subversion では次のようにします。</para>
<screen>
$ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.0
@@ -1183,7 +1185,7 @@
同じく 1.0.x ブランチ上で準備され、リリースの準備が出来次第、
1.0.1 のタグが打たれます。
1.0.2 に向けて繰り返しブランチを綺麗にしていきましょう。
- 1.1.x リリースラインにについて考え始める時期が来たら、
+ 1.1.x リリースラインについて考え始める時期が来たら、
新しいブランチを trunk から作ります。
CVS では次のようにします。
</para>
@@ -1193,7 +1195,7 @@
$ cvs tag -b RELEASE_1_1_X
</screen>
-<para>Subversion では下のようにします。</para>
+<para>Subversion では次のようにします。</para>
<screen>
$ svn copy http://.../repos/trunk http://.../repos/branches/1.1.x
@@ -1238,14 +1240,14 @@
-->
<para>
- これは勿論、リリースブランチに限ったやり方ではありません。
+ ここで説明したことが、リリースブランチの唯一の使い方ではありません。
自分が参加していたプロジェクトではとてもうまくいっていたのに、
ある状況下ではうまくいかないことがあるかもしれません。
- うまくいきそうな戦略を使ってください。
+ うまくいきそうなやり方を使ってください。
しかし、以下の点は重要なので覚えておきましょう。
つまり、リリースブランチの目的は、
日々の開発作業によって生まれる変化からリリース作業を分離することと、
- リリースプロセスを組織的に行うために、
+ リリース作業を組織的に行うために、
物理的な作業スペースをプロジェクトに与えることです。
このプロセスは次の節で説明します。
</para>
@@ -1256,11 +1258,21 @@
<sect1 id="stabilizing-a-release">
<title>リリースを安定させる</title>
+<!--
<para><firstterm>Stabilization</firstterm> is the process of getting a
release branch into a releasable state; that is, of deciding which
changes will be in the release, which will not, and shaping the branch
content accordingly.</para>
+-->
+
+<para>
+ <firstterm>リリースの安定化</firstterm> とは、
+ リリースブランチをリリースできる状態に持っていく作業です。
+ つまり、どの変更をリリースに含めるか、含めないかを決定し、
+ その方針に従ってブランチを整備することです。
+</para>
+<!--
<para>There's a lot of potential grief contained in that word,
"deciding". The last-minute feature rush is a familiar phenomenon in
collaborative software projects: as soon as developers see that a
@@ -1272,7 +1284,22 @@
next one. The more changes one tries to cram into a release at the
last minute, the more the code is destabilized, and (usually) the more
new bugs are created.</para>
+-->
+
+<para>
+ この "決定" という言葉には、厄介なことがたくさん含まれています。
+ リリース直前に新機能がたくさん出てくるのは、
+ 協調的なソフトウェアプロジェクトでは日常茶飯事です。
+ 開発者はリリースが近いことを知ると、
+ それに乗り遅れまいとして大急ぎで変更作業を終えようとします。
+ これは勿論、リリースするときにはまさに起こって欲しくないことです。
+ 開発者は自分の好きなペースで新機能を実装していればいいのであって、
+ 自分の変更が今回、または次のリリースに含まれるかどうかは心配しない方が望ましいのです。
+ ひとつのリリースに多くの変更を直前に詰め込もうとすればするほど、
+ コードは不安定になり、（普通）多くのバグが発生してしまうのです。
+</para>
+<!--
<para>Most software engineers agree in theory on rough criteria for
what changes should be allowed into a release line during its
stabilization period. Obviously, fixes for severe bugs can go in,
@@ -1288,7 +1315,25 @@
changes admitted into the release, then there will be plenty of people
motivated to allow changes, and not enough people motivated to bar
them.</para>
+-->
+
+<para>
+ ほとんどのソフトウェアエンジニアは、
+ リリースを安定化する過程でどの変更をリリースに取り込むべきかについて、
+ おおまかな点で一致しています。深刻なバグ、
+ 特に回避しようがないバグの修正は含めていいでしょう。
+ ドキュメントの更新も含めていいでしょうし、エラーメッセージの修正も同様です。
+ （但し、それがインターフェイスの一部と考えられていて、
+ 安定していなければいけない場合は別です）
+ 多くのプロジェクトでは、リスクが低いか、コアに影響しないある種の変更も受け入れますし、
+ リスクを測るための正式なガイドラインもあるでしょう。
+ しかし、どんな基準があっても人間の判断は必ず必要です。
+ 変更をリリースに取り込むか否かをプロジェクトが決めなければいけないのは日常茶飯事でしょう。
+ 危険なのは、開発者それぞれが自分の変更をリリースに含めたいと思っているので、
+ 変更を受け入れることを望む人は多いのに、それに対してNOという人が少ないことです。
+</para>
+<!--
<para>Thus, the process of stabilizing a release is mostly about
creating mechanisms for saying "no". The trick for open source
projects, in particular, is to come up with ways of saying "no" that
@@ -1301,10 +1346,25 @@
that discourage your project from being creative. Plenty of other
arrangements are possible; these are just two that I've seen work in
practice.</para>
+-->
+
+<para>
+ そういうわけで、リリースを安定化させるプロセスは、
+ ほとんどが "NO" と言う仕組みを作ることと同じです。
+ オープンソースプロジェクトに特有なトリックは、
+ 開発者を傷つけたり、がっかりさせることなく "NO" といいつつ、
+ 価値がある変更はリリースに取り込むようにする方法に知恵を絞っています。
+ たくさんの方法がありますが、いったん開発チームがそれらを重要な基準として注目すれば、
+ 基準を満たす仕組みを作るのは簡単です。
+ ここではもっとも両極端な、人気のあるやり方をふたつ簡単に説明しますが、
+ 二つだけにすることで、プロジェクトが創造性をなくしてはいけません。
+ 他のやり方はたくさんあるでしょうから、
+ 実際に使われているのを私が見たことがあるふたつだけに留めておきます。
+</para>
<!-- ======================== subsection ============================== -->
<sect2 id="release-owner">
-<title>Dictatorship by Release Owner</title>
+<title>リリースオーナーによる独裁</title>
<para>The group agrees to let one person be the <firstterm>release
owner</firstterm>. This person has final say over what changes make
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
