Add japanese translation for lifecycle

Author: azuchi

_data/navigation.yml

@@ -337,7 +337,7 @@ ja:
         url:   "/en/bips/"
       eol:
         title: "ライフサイクル"
-        url:   "/en/lifecycle"
+        url:   "/ja/lifecycle"
   contact:
     title: "コンタクト"
     submenu: true

_posts/ja/pages/2016-01-15-lifecycle.md

@@ -0,0 +1,85 @@
+---
+title: ソフトウェアライフライクル
+name: software-life-cycle
+id: ja-software-life-cycle
+permalink: /ja/lifecycle/
+layout: page
+type: pages
+lang: ja
+share: false
+version: 2
+---
+{% include toc.html %}
+
+このドキュメントではBitcoin CoreプロジェクトによりリリースされるBitcoin Coreソフトウェアパッケージのライフサイクルについて説明します。このライフサイクルは商用ソフトウェアの標準的なメンテナンスポリシーに沿っています。
+
+## バージョン管理 {#versioning}
+
+Bitcoin Coreは0.MAJOR.MINORという形式でバージョン管理され、その後ろにrc1、rc2などのリリース候補が付きます。
+
+## メジャーリリース {#major-releases}
+
+私達は6〜7ヶ月毎のメジャーリリースを目指しています。
+
+メジャーリリースには、0.11.0、0.12.0といった番号が付けられます。
+
+## メンテナンスリリース {#maintenance-releases}
+
+メジャーリリースのバグを修正するメンテンナンスの「マイナーリリース」を提供します。一般的なルールとして、メンテナンスリリースでは（コンセンサスルールを除いて）重要な新しい機能を導入していません。ただし、必要に応じてマイナーな機能を追加したり、ソフトフォークなどによるコンセンサスルールの変更をバックポートすることがあります。
+
+マイナーリリースには、0.11.1、0.11.2、0.12.1、0.12.2といった番号が付けられます。
+
+## コンセンサスルール {#consensus-rules}
+
+コンセンサスルールを変更する提案は、常に0.11.2、0.12.1などの最初のメンテナンスバージョンでリリースされます。これにより、メジャーリリースに比べてチェンジセットが少なくなるため、エンタープライズユーザーにとって提案の評価とテストが容易になります。またより慎重なアップデートパスをとるユーザーにとっては、コンセンサスルールの変更をより適切な時期に採用することができるようになります。
+
+## メンテナンス期間 {#maintenance-period}
+
+私達はメジャーバージョンを「メンテナンス終了日」までメンテナンスします。通常、現在およびその1つ前のメジャーリリースをメンテナンスします。
+例えば現在のリリースが0.13の場合、0.12もメンテナンスされているとみなされます。
+0.14がリリースされると、0.12はメンテナンス終了とみなされます。
+古いメジャーリリースは、より重大な問題があればバックポートされる必要があり、より多くの新しいマイナーリリースを保証します。
+ソフトウェアが「メンテナンス終了日」に達すると、EOLの日付まで重大セキュリティの修正が適用されます。
+EOL後は、セキュリティアップデートを受けるには、コミュニティが重要な問題の修正をベストエフォートで提供したとしても、ユーザーは新しいバージョンにアップグレードしセキュリティアップデートを受け取る必要があります。
+一般的に、現在のバージョンもしくは１つ前のバージョンの最新のメンテナンスリリース（ポイントリリース）の実行を推奨します。
+
+マイナーバージョンにはバグ修正、翻訳の更新、およびソフトフォークがあります。[Transifex][bitcoin-transifex-link]の翻訳は最新の２つのメジャーバージョンのみ受け付けています。
+
+例えば、メジャーバージョン0.9は2014-03-19にリリースされ、メンテナンス修正（ポイントリリース）は2015-06-16まで提供されました。
+重大なセキュリティ問題は、2016-02-28のEOLの日付までは引き続き修正されます。
+ただし、それ以外のバグ修正を利用するにはその後のメジャーバージョンにアップグレードする必要があります。
+
+## スケジュール {#schedule}
+
+EOLを迎えると、新しいバージョンにアップグレードする必要があります。
+
+| バージョン | リリース日 | メンテナンス終了日 | EOL |
+|---------|--------------|-----------------|-------------|
+{% include posts/maintenance-table.md %}
+
+\* _私達は6〜7ヶ月毎にメジャーリリースを目指しています。_
+
+_TBA: 追って発表されます_
+
+## プロトコルのバージョン管理 {#protocol-versioning}
+
+上記の説明はBitcoin Coreのソフトウェアリリースについてのみ説明しています。Bitcoinシステムの他の多くの部分には、それぞれ独自のバージョンが含まれています。例えば：
+
+- 各**トランザクション**にはバージョン番号が含まれます。
+- **P2Pネットワークプロトコル**はバージョン番号を使って、ノードがサポートする機能を通知できるようにしています。
+- Bitcoin Coreの**組み込みウォレット**は独自の内部バージョン番号があります。
+
+これらのバージョン番号はBitcoin Coreのバージョン番号と意図的に切り離されています。これはBitcoin Coreプロジェクトが（ブロックやトランザクションのように）直接コントロールできなかったり、（ネットワークプロトコルのように）他のプロダクトとの互換性を維持する必要があったり、または（組み込みウォレットのように）いくつかのリリースで大きな変更が行われない可能性があるためです。
+
+コンセンサスプロトコル自体にはバージョン番号はありません。
+
+## SemVerとの関係 {#relationship-to-semver}
+
+Bitcoin Coreのソフトウェアのバージョン管理は、[SemVer][]のオプションのバージョン管理標準には準拠していませんが、リリースのバージョン管理は表面的に似ています。SemVerは個人が自分のペースでライブラリのアップグレードを選択したり、変更が気にいらなければ古いリリースのままにしておくこともできる通常のソフトウェアライブラリで使用するよう設計されています。
+
+Bitcoinの一部、特にコンセンサスルールは、そのように機能しません。新しいコンセンサスルールが発効するためには、いくつかのマイナー、フルノードまたはその両方によって強制されなければなりません。また新しいルールが一度発効すると、 新しいルールを知らないソフトウェアは無効なトランザクションを作成したり受け入れたりする可能性があります（ただし、アップグレードは可能な限りこういったことが起こらないよう設計されています）。
+
+このため、Bitcoin Coreはネットワーク全体の導入が必要もしくは望ましいコンセンサスルールの変更やその他の更新についてSemVerから逸脱しています。Bitcoin Coreはこれらの変更をメジャーリリース（`0.x.0`）ではなくメンテナンスリリース（`0.x.y`）としてリリースします。これによりパッチサイズが最小限に抑えられ、できるだけ多くの人がその内容を検査、テストし、展開することが容易になります。また、同じパッチを複数の以前のメジャーリリースにバックポートすることが可能になり、簡単にアップグレードできるユーザー数が増えます。ただ、それを管理するボランティアは必ずしも十分ではありません。
+
+[SemVer]: https://semver.org/
+[bitcoin-transifex-link]: https://www.transifex.com/bitcoin/bitcoin/