contributing/community/releases.rst 翻訳

contributing/community/releases.rst

@@ -0,0 +1,166 @@
+.. note::
+
+    * 対象バージョン: 2.2以上
+    * 翻訳更新日: 2014/06/27
+
+リリースプロセス
+===================
+
+このドキュメントは、 Symfony のリリースプロセスについて説明しています。（ Symfony は ``symfony/symfony`` `Gitレポジトリ`_ でホストされています）
+
+Symfony は *時間ベースのモデル* でリリースを管理しています。
+Symfony の新しいマイナーバージョンは *6ヶ月* おき、つまり *5月* と*11月* にリリースされます。
+
+.. tip::
+
+    「マイナー」の意味は `Semantic Versioning`_ から来ています。
+
+各マイナーバージョンは、開発期間とメンテナンス期間という、あらかじめはっきりと決められたプロセスを辿ります。
+
+.. note::
+
+    このリリースプロセスは Symfony 2.2 から適用され、このドキュメントで説明されている
+    全ての規則は Symfony 2.4 以降に厳格に適用されなければなりません。
+
+.. _contributing-release-development:
+
+開発
+-----------
+
+開発期間は6ヶ月間続き、2つのフェーズに分かれています。
+
+* *開発*: *4ヶ月間* 新しい機能の追加や既存機能の拡張のための期間です。
+
+* *安定化*: *2ヶ月間* バグの修正、リリース準備、全ての Symfony エコシステム（サードパーティのライブラリやバンドル、Symfony を利用しているプロジェクト）が対応するのを待つための期間です。
+
+開発フェーズの間、新しい機能は、開発フェーズの終了までに実装が間に合わない場合や、最終リリースまでに安定化させられない場合、差し戻されます。
+
+.. _contributing-release-maintenance:
+
+メンテナンス
+-------------
+
+Symfony のマイナーバージョンは、リリースのタイプによって異なる一定期間メンテナンスされます。
+メンテナンス期間は2種類あります。
+
+* *バグ修正、セキュリティ上の問題の修正*: 全ての issue を直すことができる期間です。
+  この期間の終了をもって、各リリースの *end of maintenanse* と呼びます。
+
+* *セキュリティ上の問題の修正*: セキュリティに関係する issue のみを修正する期間です。
+  この期間の終了をもって、各リリースの *end of life* と呼びます。
+
+スタンダードバージョン
+~~~~~~~~~~~~~~~~~~~~~~~
+
+通常のマイナーバージョンは、バグ修正期間として *8ヶ月間* 、セキュリティ問題のみの修正期間として *14ヶ月間* メンテナンスされます。 
+
+長期サポートバージョン
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+2年ごとに、新しい長期サポートバージョン（ LTS バージョン）が公開されます。
+LTS バージョンはバグ修正期間として *3年間* 、セキュリティ問題のみの修正期間として *4年間* サポートされます。
+
+.. note::
+
+    コミュニティによる3年間のサポートの後、 `SensioLabs`_ から有償サポートを受けることもできます。
+
+スケジュール
+--------------
+
+下図はこのリリースモデルが適用される最初のバージョンのリリーススケジュールです。
+
+.. image:: /images/release-process.jpg
+   :align: center
+
+* **黄色** は開発期間
+* **青色** は安定化期間
+* **緑色** はメンテナンス期間
+
+このスケジュールによって、リリース日とメンテナンス期間は下記のようになることがわかります。
+
++---------+---------+---------------------+-------------+
+| Version | Release | End of Maintenance  | End of Life |
++=========+=========+=====================+=============+
+| 2.0     | 07/2011 | 03/2013 (20 months) | 09/2013     |
++---------+---------+---------------------+-------------+
+| 2.1     | 09/2012 | 05/2013 (9 months)  | 11/2013     |
++---------+---------+---------------------+-------------+
+| 2.2     | 03/2013 | 11/2013 (8 months)  | 05/2014     |
++---------+---------+---------------------+-------------+
+| **2.3** | 05/2013 | 05/2016 (36 months) | 05/2017     |
++---------+---------+---------------------+-------------+
+| 2.4     | 11/2013 | 07/2014 (8 months)  | 01/2015     |
++---------+---------+---------------------+-------------+
+| 2.5     | 05/2014 | 01/2015 (8 months)  | 07/2016     |
++---------+---------+---------------------+-------------+
+| 2.6     | 11/2014 | 07/2015 (8 months)  | 01/2016     |
++---------+---------+---------------------+-------------+
+| **2.7** | 05/2015 | 05/2018 (36 months) | 05/2019     |
++---------+---------+---------------------+-------------+
+| 2.8     | 11/2015 | 07/2016 (8 months)  | 01/2017     |
++---------+---------+---------------------+-------------+
+| ...     | ...     | ...                 | ...         |
++---------+---------+---------------------+-------------+
+
+.. tip::
+
+    Symfony の特定のバージョンについて、上記のようなスケジュールを調べたいときは、
+    オンラインの `timeline calculator`_ を使ってください。
+    `http://symfony.com/roadmap.json?version=2.x` のような URL にアクセスすると
+    全てのデータを JSON 形式で取得することもできます。
+
+.. tip::
+
+    Symfony のバージョンに関連する重要な出来事（例えばバージョンが end of maintenance
+    に至ったり、新しいパッチバージョンがリリースされたり）について、
+    メール通知を受け取ることもできます。 `roadmap notification`_ ページから登録してください。
+
+後方互換性
+-----------------------
+
+
+Symfony の :doc:`Backwards Compatibility Promise </contributing/code/bc>` はとても厳格で
+開発者が、あるマイナーバージョンから次のマイナーバージョンへ安心してアップグレードするのに役立ちます。
+
+後方互換性を維持できない場合は常に、新機能や機能拡張やバグ修正は次のメジャーバージョンに繰り越されます。
+
+.. note::
+
+    Symfony の新しいメジャーバージョンの開発は、後方互換性を保たない主要な機能がリスト上に
+    充分にたまり次第、いつでも始められます。
+
+機能の廃止
+--------------
+
+ある機能の実装が、後方互換性を壊さずによりよく書き換えることができなくなったとき、
+古い実装を廃止予定として残したまま、新しくより良い実装を並べて追加することもできます。
+Symfony で機能の廃止を扱う方法についての詳細は、 :ref:`conventions <contributing-code-conventions-deprecations>` を参照してください。
+
+なぜこの決まりが存在するのか
+-----------------------------
+
+Symfony のリリースプロセスは、 *予測可能性* と *透明性* を高めるために適用されます。
+下記の目標を目指して議論され、決定されました。
+
+* リリースサイクルを短くすること（開発者に新しい機能をより早く提供すること）。
+* フレームワークを使う開発者や Symfony を利用しているオープンソースプロジェクトのために、可視性を高めること。
+* Symfony コアのコントリビューターの体験を向上させること。つまり、 Symfony の各機能がいつから利用可能か誰でもわかるようにすること。
+* Symfony を利用したり Symfony と連携する PHP プロジェクトとSymfonyのタイムラインを合わせること。
+* Symfony エコシステム（バンドル作者、ドキュメントの書き手、翻訳者など）に新しいバージョンに追いつくための時間を与えること。
+
+6か月という期間は、1年に2回のリリースがちょうど良いということで選ばれました。
+それだけでなく、新しい機能のために作業時間を充分に確保できたり、安定性がまだ充分ではない
+機能について、次のリリースサイクルまで待ち時間が長すぎる必要もないという理由もあります。
+
+2つのメンテナンスモードは全ての Symfony のユーザーをハッピーにするために定められました。
+最新で最善の Symfony を使いたい開発者は、通常のバージョンを使ってください。新しいバージョンが6か月ごとにリリースされ、2か月間の移行期間があります。
+より安定性を求める開発者は、 LTS バージョンを使ってください。新しいバージョンは2年ごとにリリースされ、移行期間は1年間あります。
+
+.. _Semantic Versioning: http://semver.org/
+.. _Gitレポジトリ: https://github.com/symfony/symfony
+.. _SensioLabs:     http://sensiolabs.com/
+.. _roadmap notification: http://symfony.com/roadmap
+.. _timeline calculator: http://symfony.com/roadmap
+
+.. 2014/06/27 77web 6e6601aca98748e095066f6301b20b979902607d
+