リリース計画
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
はじめに
時間に基づいたリリースの連続は高品質のフリーソフトウェアを生みだすとされています。時間に基づいたリリースは、機能やバグ修正のいずれをも待ちません。けれども（できるだけ純粋に）時間にもとづきます。これは、修正を入れる規則を強化し、予測しやすくなり、より規則的なリリースを可能にします。毎回同様に、私たちは必然的に、早く、そして急速に、以前の安定したバージョンを基に追加的にバグ修正版をリリースします。したがって、あなたが最高品質のバージョンを必要としているならば、1番目あるいは2番目のマイナー・ポイント・リリースまで採用を延期するのが良い判断かもしれません。
- LibreOfficeは他のフリーソフトウェア（例:GNOME）と同じく、年に2回あらかじめ決められた時期にリリースを行います。これは主なLinuxディストリビューションのリリースの最低でも1ヶ月前です。
- 時間ベースのリリーススケジュールをより広範なフリーソフトウェアのエコシステムと同期させることは、配布サイクルの遅れを最小限に抑えつつ、できるだけ早く新機能をユーザーに提供できるという大きな利点もあります。そのため、私たちは6ヶ月ごとのリリースを目標として、時間をかけて3月/9月という基準に合わせて微調整していきます。
- Fresh（最新リリース）とStill（以前のリリース）の2つのブランチがあります。それぞれは、メインストリームである機能を重視するユーザーと、保守的だったり企業での展開を対象としています。
- As a result, users get a new major release every six months with a wide range of features, fixes and enhancements. They will also receive many bug-fixing 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.3/X.Y.4 bugfix release.
リリースに技術的またはその他の深刻な問題がある場合、スケジュールに記載されている日がずれる可能性があるので注意してください。最終リリース候補に致命的な問題があった場合、追加のリリース候補が必要になることがあります。このような場合は1週間ほど最終リリースを遅らせます。その決定はEngineering Steering Committeeで行われます。
以下の単純化されたグラフは、3つのリリースを24ヶ月のタイムラインで示しています。
24.2 リリース
| リリース | 凍結 | 公開 |
|---|---|---|
| 24.2.0 （凍結: 第02週） | Week 47 , 2023/11/20 - 2023/11/26 | Week 05 , 2024/01/29 - 2024/02/04 |
| 24.2.1 | Week 06 , 2024/02/05 - 2024/02/11 | Week 09 , 2024/02/26 - 2024/03/03 |
| 24.2.2 | Week 10 , 2024/03/04 - 2024/03/10 | Week 13 , 2024/03/25 - 2024/03/31 |
| 24.2.3 | Week 15 , 2024/04/08 - 2024/04/14 | Week 18 , 2024/04/29 - 2024/05/05 |
| 24.2.4 | Week 20 , 2024/05/13 - 2024/05/19 | Week 23 , 2024/06/03 - 2024/06/09 |
| 24.2.5 | Week 26 , 2024/06/24 - 2024/06/30 | Week 29 , 2024/07/15 - 2024/07/21 |
| 24.2.6 | Week 33 , 2024/08/12 - 2024/08/18 | Week 36 , 2024/09/02 - 2024/09/08 |
| 24.2.7 | Week 41 , 2024/10/07 - 2024/10/13 | Week 44 , 2024/10/28 - 2024/11/03 |
| サポート終了 | 2024/11/30 | |
See also the detailed schedule and the release notes.
7.6 リリース
| リリース | Freeze | 公開 |
|---|---|---|
| 7.6.0 （凍結: 第30週） | Week 19 , 2023/05/08 - 2023/05/14 | Week 34 , 2023/08/21 - 2023/08/27 |
| 7.6.1 | Week 34 , 2023/08/21 - 2023/08/27 | Week 37 , 2023/09/11 - 2023/09/17 |
| 7.6.2 | Week 38 , 2023/09/18 - 2023/09/24 | Week 39 , 2023/09/25 - 2023/10/01 |
| 7.6.3 | Week 44 , 2023/10/30 - 2023/11/05 | Week 47 , 2023/11/20 - 2023/11/26 |
| 7.6.4 | Week 50 , 2023/12/11 - 2023/12/17 | Week 53 , 2024/01/01 - 2024/01/07 |
| 7.6.5 | Week 05 , 2024/01/29 - 2024/02/04 | Week 08 , 2024/02/19 - 2024/02/25 |
| 7.6.6 | Week 10 , 2024/03/04 - 2024/03/10 | Week 13 , 2024/03/25 - 2024/03/31 |
| 7.6.7 | Week 16 , 2024/04/15 - 2024/04/21 | Week 19 , 2024/05/06 - 2024/05/12 |
| サポート終了 | 2024/6/12 | |
7.5 リリース
| リリース | 凍結 | 公開 |
|---|---|---|
| 7.5.0 (freeze: week 02) | Week 47 , 2022/11/21 - 2022/11/27 | Week 05 , 2023/01/30 - 2023/02/05 |
| 7.5.1 | Week 06 , 2023/02/06 - 2023/02/12 | Week 09 , 2023/02/27 - 2023/03/05 |
| 7.5.2 | Week 10 , 2023/03/06 - 2023/03/12 | Week 13 , 2023/03/27 - 2023/04/02 |
| 7.5.3 | Week 15 , 2023/04/10 - 2023/04/16 | Week 18 , 2023/05/01 - 2023/05/07 |
| 7.5.4 | Week 20 , 2023/05/15 - 2023/05/21 | Week 23 , 2023/06/05 - 2023/06/11 |
| 7.5.5 | Week 26 , 2023/06/26 - 2023/07/02 | Week 29 , 2023/07/17 - 2023/07/23 |
| 7.5.6 | Week 33 , 2023/08/14 - 2023/08/20 | Week 36 , 2023/09/04 - 2023/09/10 |
| 7.5.7 | Week 38 , 2023/09/18 - 2023/09/24 | Week 39 , 2023/09/25 - 2023/10/01 |
| 7.5.8 | Week 41 , 2023/10/09 - 2023/10/15 | Week 44 , 2023/10/30 - 2023/11/05 |
| サポート終了 | 2023/11/30 | |
日時
リリースはタイムベースですが、スケジュールは期日の代わりに週を定義します。それは私たちがいつも少し柔軟だからです。リリースはブロッカーバグ、ビルドの問題、技術的な問題により、多少は遅れることができます。
リリースは、いくつかのBeta版やリリース候補のビルドで構成されています。ビルドごとにいくつかのアクションが必要とされています。 理想的な作業の流れはこのようになります。
- 月曜日 - コミット期限; その前にリマインダーを、devel、l10n メーリングリストに送ります
- 火曜日 - ビルドがコミットされ、ユニットや後続、スモークテストをパスしたとき、タグが生成されます。タグは devel および qa メーリングリストに通知されます。
- 水曜日 - ビルドはプレリリース・サイトにアップロードされています。devel および qa メーリングリストに通知されます。
- 木曜日 - ビルドがミラーにアップロードされます。多くのチャンネル経由で公表があります、たとえば、メーリングリスト、ツイッターなど
- 金曜日 - ビルドは 公式プレリリース・サイト を通じて利用できます。
最終的なリリースの発表は通常木曜日に行われます。最後のリリース候補の数日後に出ます。
我々は最後のリリース候補版のコミットについて、厳密であることに注意してください。完全なリグレッションテストは必要ありません。必要なテストに合格すると、最終ビルドが（訳注：リリース版として）使用されます。それは（訳注：リリース候補からリリース版へ）ミラーで名前が変更されます。
スケジュール
スケジュールは以下のルールに基づいています：
- 6ヶ月ごとにメジャーリリースを行い、主なLinuxディストリビューションと同期させる。それは広い範囲で機能追加、修正と拡張がされています
- 最も保守的な人々に対しても十分になるまで、メインリリース後に毎月純粋なバグ修正リリースを行う。頻繁にそれを行う
- 次のリリースで最も保守的な人々のための準備が整うまで、セキュリティ修正を含む純粋なバグ修正リリースを行う
- 同じ週に2つのビルドは行わない
以下はテンプレートです。
| イベント | 夏 | 冬 |
|---|---|---|
| x.y 機能の凍結 | 6月上旬 | 12月上旬 |
| x.y.0 最初のリリース | 8月上旬 | 2月上旬 |
| x.y.1 バグ修正リリース | 9月上旬 | 3月上旬 |
| x.y.2 バグ修正リリース | 10月上旬 | 8月上旬 |
| x.y.3 バグ修正リリース | 11月上旬 | 5月上旬 |
| x.y.4 バグ修正リリース | 12月上旬 | 6月上旬 |
| x.y.5 バグ修正リリース | 2月中旬 | 8月中旬 |
| x.y.6 バグ修正リリース | 4月中旬 | 10月中旬 |
ここでの(b)は月初めの意味、(m)は月の中頃の意味、(e)は月末という意味です。
コードの凍結
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.
In practice, you should keep an eye on the tagging of the first release candidate. One way to find out, if RC1 has been tagged is to visit the tag view of the LibreOffice core repository in Gerrit and input into the filter field: libreoffice-X.Y.Z. If the results do not contain any entry for libreoffice-X.Y.Z.1, RC1 has not yet been tagged and string changes can still be committed.
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.
バージョン スキーム
リリースごとにいくつかのビルドを行います。これには次のバージョン管理スキームが使用されます。
- X.Y.0.0.alphaZ - 初期リリースのZ番目のアルファ版
- X.Y.0.0.betaZ -初期リリースのZ番目のベータ版
- X.Y.0.Z - 最初のリリースのZ番目のリリース候補です。最後のリリース候補は最終版とみなされ、メインダウンロードページに掲載されます。
- X.Y.1.Z - 最初のバグ修正リリースのZ番目のリリース候補です。最後のリリース候補は最終版とみなされ、メインダウンロードページに掲載されます。
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)
このスキームについて、長い議論がメーリングリスト上で行われました。
リリースサイクルの加速
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に分割されました。