Yii バージョン規約
==================

この文書は Yii のバージョン付与ポリシーを要約するものです。
私たちの現在のバージョン付与戦略は、[ferver](https://github.com/jonathanong/ferver) によって記述されているものです。
私たちはこれを [Semantic Versioning](http://semver.org/) より現実的で合理的であると考えます
(詳細については [#7408](https://github.com/yiisoft/yii2/issues/7408) を参照してください)。

コア開発者チームの内部では、2.0.x リリースを 100% 後方互換に保つことが重要であることが、何度も強調されました。
しかし、これは理想としての計画です。
ferver の記事は、Semantic Versioning を使っても使わなくても、これが現実には達成が困難な計画であることを示す現実世界の例を示しています。

要約すれば、Yii 2 に対する私たちのバージョン付与ポリシーは次のようになります。

## バージョン番号

バージョン番号は `2.x.y.z` のフォーマットとします。ここで `z` が `0` であるリリースについては、`z` は省略可能です。

将来出るであろう Yii バージョン 3 については、1.0 に対する 2.0 のようなものになると予想されるので、ここでは言及しません。
このようなことは、外的な技術進歩 (たとえば PHP の 5.0 から 5.4 へのアップグレード) によって、3年から5年に一度しか生じないものと予期しています。

## `2.X.0`: メジャーリリース

後方互換性を損ないうる大きな機能追加と変更を含む、非後方互換なリリースです。
以前のバージョンからのアップグレードは簡単ではないかも知れませんが、完全なアップグレードのガイドが提供されます。

* 主として新機能とバグ修正を含む。
* パッチリリースからマージされた小さな機能強化とバグ修正を含む。
* `UPGRADE-2.X.md` ファイルに記録される非後方互換な変更を含みうる。
* リリースのサイクルはだいたい12ヶ月またはそれ以上。
* プレリリースが必要: `2.X.0-alpha`, `2.X.0-beta`, `2.X.0-rc`
* 大きなニュースリリースとマーケティング努力を必要とする。

## `2.x.Y`: マイナーリリース

100% 後方互換であるべき、パッチリリースです。
理想的には、後方互換性を損なわない変更だけを含ませたいと私たちは望んでいます。
しかし、100% の後方互換性を常に保つことは不可能ですので、アップグレードに関するノートが `UPGRADE.md` に記録されます。
実際には、2.0.x はより頻繁にリリースされており、また、小さな機能改良をも追加して、ユーザが新機能をより早く享受できるようにしています。

* 主としてバグ修正と小さな機能強化を含む。
* 大きな機能拡張や修正はしない。
* 不安無しのアップグレードを保証するために、100% 後方互換でなければならない。ごく少数の例外は許容されるが、その場合は `UPGRADE.md` に記録される。
* リリースのサイクルは1～2ヶ月程度。
* プレリリース (alpha, beta, RC) は不要。
* 継続的に (少なくとも週に一回は手作業で) マスターブランチにマージバックされるべき。
* ニュースによる広報を伴う。プロジェクトサイトがアップデートされる。

### `2.x.y.Z`: パッチリリース

バグ修正のみを含む、100% 後方互換であるべき、パッチリリースです。
ニュースによる広報やプロジェクトサイトのアップデートはしません (ただし、重大な/セキュリティの問題についての修正を含む場合は、別です)。
このリリースのプロセスはほぼ自動的に実行されます。

* バグ修正のみを含む。機能追加はしない。
* 不安無しのアップグレードを保証するために、100% 後方互換でなければならない。唯一の例外はセキュリティ問題で、その場合は後方互換性が破られることもある。
* リリースのサイクルは1～2週間程度。
* プレリリース (alpha, beta, RC) は不要。
* リリース時にマスターブランチにマージバックされなければならない。


## ブランチ規約

* `master` ブランチは、現在の安定版メジャーリリースの開発ブランチで、現在は `2.0.x` バージョンです。
* 各メジャーリリースは、そのバージョン番号の名前を持つブランチ上で開発されます。例えば、`2.1`。
* メジャーリリース `2.n` の準備が出来たら、`master` から `2.(n-1).x` と名付けられた保守ブランチを作成します。
例えば、バージョン `2.1.0` が安定版としてリリースされ、`master` 上で開発されるようになると、`2.0` ブランチが作成されます。
  ([composer branch naming schema](https://getcomposer.org/doc/02-libraries.md#branches) を参照).
* パッチリリースをマークするために `2.x.y.z` というタグと `2.x.y` ブランチを作成します。`0` は省略されます。
* `2.n.x` 保守ブランチ上の変更は、継続的に `master` ブランチにマージバックされます。

次の図は、各ブランチ上でのコミット履歴の経時的な変化を説明したものです。

![ブランチ規約](versions-branches.png)


## リリース

Yii 2 フレームワークと公式エクステンションのプロジェクトは、ともに、上述のバージョン規約およびブランチ規約に従います。
ただし、フレームワークと公式エクステンションのプロジェクトは、お互いに独立にリリースされます。
すなわち、すなわち、フレームワークとエクステンションの間で、バージョン番号が異なることが予想されます。
アプリケーションテンプレートは、常に、フレームワークと同時にリリースされます。

上記で説明されたリリースサイクルは、コアフレームワークにのみ適用されます。
エクステンションは必要に応じてリリースされます。
エクステンションは、何らバグ修正や機能拡張を受けずに、長期間にわたって新しいリリースを持たないことがあり得ます。