リリース計画

From The Document Foundation Wiki
Jump to: navigation, search
本ページはGlobal Wikiからの有志による翻訳ページです。未翻訳があることや内容が古い場合があります。最新化、翻訳にご協力お願いします。
日本語独自の情報についてまとめることを目的として、日本語コミュニティによって運営されているページとして 日本語コミュニティ独自ページ があります。
URLが wiki.documentfoundation.org/JA で始まっていて、カテゴリーがJAのページです。
そちらもご利用ください。

イントロダクション

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

  • LibreOffice does bi-annual, predictable releases that are in sync with other Free Software projects (eg. Gnome) and are at least one month ahead major Linux distribution releases.
  • 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週間またはそれ以上最終リリースをシフトさせます。

6.2 リリース

当初リリースとバグフィックスリリースのための基本日程
バージョン 凍結 公開
6.2.0 (freeze: week 02) Week 42 , Oct 15, 2018 - Oct 21, 2018 Week 05 , Jan 28, 2019 - Feb 3, 2019
6.2.1 Week 05 , Jan 28, 2019 - Feb 3, 2019 Week 08 , Feb 18, 2019 - Feb 24, 2019
6.2.2 Week 09 , Feb 25, 2019 - Mar 3, 2019 Week 12 , Mar 18, 2019 - Mar 24, 2019
6.2.3 Week 13 , Mar 25, 2019 - Mar 31, 2019 Week 16 , Apr 15, 2019 - Apr 21, 2019
6.2.4 Week 18 , Apr 29, 2019 - May 5, 2019 Week 21 , May 20, 2019 - May 26, 2019
6.2.5 Week 24 , Jun 10, 2019 - Jun 16, 2019 Week 27 , Jul 1, 2019 - Jul 7, 2019
6.2.6 Week 30 , Jul 22, 2019 - Jul 28, 2019 Week 33 , Aug 12, 2019 - Aug 18, 2019
6.2.6 Week 39 , Sep 23, 2019 - Sep 29, 2019 Week 42 , Oct 14, 2019 - Oct 20, 2019
End of Life November 30, 2019

6.1 リリース

当初リリースとバグフィックスリリースのための基本日程
バージョン 凍結 公開
6.1.0 (freeze: week 29) Week 17 , Apr 23, 2018 - Apr 29, 2018 Week 32 , Aug 6, 2018 - Aug 12, 2018
6.1.1 (initially week 35) Week 32 , Aug 6, 2018 - Aug 12, 2018 Week 37 , Sep 10, 2018 - Sep 16, 2018
6.1.2 (shortened to one rc) Week 38 , Sep 17, 2018 - Sep 23, 2018 Week 39 , Sep 24, 2018 - Sep 30, 2018
6.1.3 Week 41 , Oct 8, 2018 - Oct 14, 2018 Week 44 , Oct 29, 2018 - Nov 4, 2018
6.1.4 Week 48 , Nov 26, 2018 - Dec 2, 2018 Week 51 , Dec 17, 2018 - Dec 23, 2018
6.1.5 Week 3 , Jan 14, 2019 - Jan 20, 2019 Week 6 , Feb 4, 2019 - Feb 10, 2019
6.1.6 Week 15 , Apr 8, 2019 - Apr 14, 2019 Week 18 , Apr 29, 2019 - May 5, 2019
End of Life May 29, 2019

詳細スケジュールリリースノートも見てください。

6.0 リリース

当初リリースとバグフィックスリリースのための基本日程
バージョン 凍結 公開
6.0.0 (freeze: week 2) Week 42 , Oct 16, 2017 - Oct 22, 2017 Week 5 , Jan 29, 2018 - Feb 4, 2018
6.0.1 Week 6 , Feb 5, 2018 - Feb 11, 2018 Week 6 , Feb 5, 2018 - Feb 11, 2018
6.0.2 Week 8 , Feb 19, 2018 - Feb 25, 2018 Week 9 , Feb 26, 2018 - Mar 4, 2018
6.0.3 Week 11 , Mar 12, 2018 - Mar 18, 2018 Week 14 , Apr 2, 2018 - Apr 8, 2018
6.0.4 Week 16 , Apr 16, 2018 - Apr 22, 2018 Week 19 , May 7, 2018 - May 13, 2018
6.0.5 Week 22 , May 28, 2018 - Jun 3, 2018 Week 25 , Jun 18, 2018 - Jun 24, 2018
6.0.6 Week 28 , Jul 9, 2018 - Jul 15, 2018 Week 31 , Jul 30, 2018 - Aug 5, 2018
6.0.7 Week 40 , Oct 1, 2018 - Oct 7, 2018 Week 43 , Oct 22, 2018 - Oct 28, 2018
End of Life November 26, 2018

詳細スケジュールリリースノートも見てください。

5.4 リリース

当初リリースとバグフィックスリリースのための基本日程
バージョン 凍結 公開
5.4.0 (freeze: week 27) Week 17 , Apr 24, 2017 - Apr 30, 2017 Week 30 , Jul 24, 2017 - Jul 30, 2017
5.4.1 Week 32 , Aug 7, 2017 - Aug 13, 2017 Week 35 , Aug 28, 2017 - Sep 3, 2017
5.4.2 Week 37 , Sep 11, 2017 - Sep 17, 2017 Week 40 , Oct 2, 2017 - Oct 8, 2017
5.4.3 Week 42 , Oct 16, 2017 - Oct 22, 2017 Week 45 , Nov 6, 2017 - Nov 12, 2017
5.4.4 Week 48 , Nov 27, 2017 - Dec 3, 2017 Week 51 , Dec 18, 2017 - Dec 24, 2017
5.4.5 Week 4 , Jan 22, 2018 - Jan 28, 2018 Week 6 , Feb 5, 2018 - Feb 11, 2018
5.4.6 Week 9 , Feb 26, 2018 - Mar 4, 2018 Week 12 , Mar 19, 2018 - Mar 25, 2018
5.4.7 Week 15 , Apr 9, 2018 - Apr 15, 2018 Week 18 , Apr 30, 2018 - May 6, 2018
End of Life June 11, 2018

詳細スケジュールリリースノートも見てください。

日時

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

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

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

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

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

スケジュール

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

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

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

連結したリリース
イベント
x.y feature freeze jun(b) Dec(b)
x.y.0 first release Aug(b) Feb(b)
x.y.1 bugfix release Sep(b) Mar(b)
x.y.2 bugfix release Oct(b) Apr(b)
x.y.3 bugfix release Nov(b) May(b)
x.y.4 bugfix release Dec(b) Jun(b)
x.y.5 bugfix release Feb(m) Aug(m)
x.y.6 bugfix release Apr(m) Oct(m)

、(b)は月初めの意味、(m)は月の中頃の意味、(e)は月末の意味です。

バージョン体系

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.0.Z - 最初のリリースののリリース候補のZ番目。最後のリリース候補はダウンロードページに置かれます
  • X.Y.1.Z - 1つ目のバグフィックス・リリースの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)

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

リリースサイクルの加速

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プロバイダーをお勧めします。

Because of the amount of data, the releases were split out to ReleasePlan/Archive.