ReleasePlan/ja

はじめに
時間に基づいたリリースの連続は高品質のフリーソフトウェアを生みだすとされています. 時間に基づいたリリースは、機能やバグ修正のいずれをも待ちません. けれども（できるだけ純粋に）時間にもとづきます. これは、修正を入れる規則を強化し、予測しやすくなり、より規則的なリリースを可能にします. 毎回同様に、私たちは必然的に、早く、そして急速に、以前の安定したバージョンを基に追加的にバグ修正版をリリースします. したがって、あなたが最高品質のバージョンを必要としているならば、1番目あるいは2番目のマイナー・ポイント・リリースまで採用を延期するのが良い判断かもしれません.


 * LibreOfficeは他のフリーソフトウェア（例えば、GNOME）と同じく、年に2回あらかじめ決められた時期にリリースを行います. これは主なLinuxディストリビューションのリリースの最低でも1ヶ月前です.


 * Synchronizing time-based release schedule with the wider Free Software ecosystem also has huge advantages, by getting our new features, out to users as quickly as possible – with a minimum of distribution cycle lag. In consequence, we aim at six monthly releases, and over time nudge them to align well with the March/September norms.


 * Time-based release trains have been shown to produce the best quality Free software. A time based release is one that does not wait for either features, or bug fixes - but is based (as purely as possible) on time. This enforces discipline in introducing fixes, gives predictability, and allows more regular releasing. It is also the case that we will necessarily release earlier, and then rapidly, incrementally bug fix releases based on the previous stable version. Thus if you have a need for the very highest quality version, it can make sense to defer a move until the first or perhaps second minor point release.


 * There are 2 branches: Fresh (the newest release) and Still (the previous release), which are intended for mainstream feature users and conservative, corporate deployments respectively.


 * As a result, users get new major version every six months with a wide range of features, fixes, and enhancements. In addition, they get many pure bugfix micro releases. The first X.Y.0 release is intended for early adopters. More conservative users are advised to wait for a later X.Y.Z bugfix release.

リリースに技術的またはその他の深刻な問題がある場合、スケジュールに記載されている日がずれる可能性があるので注意してください. 最終リリース候補がリリース基準に満たない場合、追加のリリース候補が必要になることがあります. このような場合は1週間またはそれ以上最終リリースを遅らせます.

The simplified graphic below shows three releases placed on a timeline consisting of 24 months.

将来のリリース Fresh Still

7.4 リリース
スケジュールの詳細とリリースノートもご覧ください.

7.3 リリース
See also the detailed schedule and the release notes.

7.2 リリース
スケジュールの詳細とリリースノートもご覧ください.

7.1 リリース
スケジュールの詳細とリリースノートもご覧ください.

7.0 リリース
スケジュールの詳細とリリースノートもご覧ください.

6.4 リリース
スケジュールの詳細とリリースノートもご覧ください.

6.3 リリース
スケジュールの詳細とリリースノートもご覧ください.

日時
リリースはタイムベースですが、スケジュールは期日の代わりに週を定義します. それは私たちがいつも少し柔軟だからです. リリースはブロッカーバグ、ビルドの問題、技術的な問題により、多少は遅れることができます.

リリースは、いくつかのBeta版やリリース候補のビルドで構成されています. ビルドごとにいくつかのアクションが必要とされています. 理想的な作業の流れはこのようになります.


 * 月曜日 - コミット期限; その前にリマインダーを、devel、l10n メーリングリストに送ります
 * 火曜日 - ビルドがコミットされ、ユニットや後続、スモークテストをパスしたとき、タグが生成されます. タグは devel および qa メーリングリストに通知されます.
 * 水曜日 - ビルドはプレリリース・サイトにアップロードされています. devel および qa メーリングリストに通知されます.
 * 木曜日 - ビルドがミラーにアップロードされます. 多くのチャンネル経由で公表があります、たとえば、メーリングリスト、ツイッターなど
 * 金曜日 - ビルドは 公式プレリリース・サイト を通じて利用できます.

最終的なリリースの発表は通常木曜日に行われます. 最後のリリース候補の数日後に出ます.

我々は最後のリリース候補版のコミットについて、厳密であることに注意してください. 完全なリグレッションテストは必要ありません. 必要なテストに合格すると、最終ビルドが（訳注：リリース版として）使用されます. それは（訳注：リリース候補からリリース版へ）ミラーで名前が変更されます.

スケジュール
スケジュールは以下のルールに基づいています：


 * 6ヶ月ごとにメジャーリリースを行い、主なLinuxディストリビューションと同期させる. それは広い範囲で機能追加、修正と拡張がされています
 * 最も保守的な人々に対しても十分になるまで、メインリリース後に毎月純粋なバグ修正リリースを行う. 頻繁にそれを行う
 * 次のリリースで最も保守的な人々のための準備が整うまで、セキュリティ修正を含む純粋なバグ修正リリースを行う
 * 同じ週に2つのビルドは行わない

以下はテンプレートです.

ここでの(b)は月初めの意味、(m)は月の中頃の意味、(e)は月末という意味です.

String freeze
The release plans for the first version of each major release indicate a "hard English string & UI freeze". The idea is to make the lives of translators easier. The translators should be able to trust that no new translatable strings are added into the UI or Help files between the period of the string freeze and release.

After the first version of a major release is out, correcting mistakes in the UI and Help strings is fine. Any completely new content should target the next major release.

Version scheme
We do several builds around each release. The following versioning scheme is used:


 * X.Y.0.0.alphaZ - 初期リリースのZ番目のアルファ版
 * X.Y.0.0.betaZ -初期リリースのZ番目のベータ版
 * X.Y.0.Z - Zth release candidate of the initial release, last rc is considered as final and put on the main download page
 * X.Y.1.Z - Zth release candidate of the 1st bugfix release, last rc is considered as final and put on the main download page

It seems to be the best compromise with the following advantages:


 * easy to understand for normal users, alpha, beta flags are known from other projects, so they set reasonable expectations
 * correct alphabetical sorting in RPM, Bugzilla
 * “easy” to parse (alpha/beta strings delimited by dot)

There was a long discussion about this scheme on the mailing list.

Accelerating the release cycle
This acceleration of the release cycle involves some considerable release engineering and QA effort. To reduce the cost of these, we work to provide complete (ie. containing all languages) daily snapshots of the master branch to allow continual testing of code improvements. This works partially already, as can be seen/downloaded from here.

Similarly, we plan to increasingly automate the build process to allow a much lower-touch release flow, and to continue to shrink the footprint of our binaries to allow far more rapid transfer of product-equivalent builds.

サポート終了したリリース
リリースは通常およそ9ヶ月の寿命を持っています. 私たちは最後の計画リリース（訳注：例えば4.0の最後の計画リリースは4.0.6です）の1ヶ月後にサポート終了 (EOL)に達しているとみなします.

リリースの長期的なサポートが必要な場合は、認定開発者が関わる、サービスを提供することができる任意のL3プロバイダーをお勧めします.

データ量の都合により、リリースはReleasePlan/Archiveに分割されました.