リリース計画

From The Document Foundation Wiki
Jump to: navigation, search
本ページはGlobal Wikiからの有志による翻訳ページです。未翻訳があることや内容が古い場合があります。最新化、翻訳にご協力お願いします。
日本語独自の情報についてまとめることを目的として、日本語コミュニティによって運営されているページとして 日本語コミュニティ独自ページ があります。
URLが wiki.documentfoundation.org/JA で始まっていて、カテゴリーが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週間またはそれ以上最終リリースを遅らせます。

6.3 リリース

最初のリリースとバグ修正リリースの基本日程
バージョン 凍結 公開
6.3.0 (freeze: week 29) Week 19 , 2019/05/06 - 2019/05/12 Week 32 , 2019/08/05 - 2019/08/11
6.3.1 Week 32 , 2019/08/05 - 2019/08/11 Week 35 , 2019/08/26 - 2019/09/01
6.3.2 Week 36 , 2019/09/02 - 2019/09/08 Week 39 , 2019/09/23 - 2019/09/29
6.3.3 Week 41 , 2019/10/07 - 2019/10/13 Week 44 , 2019/10/28 - 2019/11/03
6.3.4 Week 47 , 2019/11/18 - 2019/11/24 Week 50 , 2019/12/09 - 2019/12/15
6.3.5 Week 04 , 2020/01/20 - 2020/01/26 Week 07 , 2020/02/10 - 2020/02/16
6.3.6 Week 15 , 2020/04/06 - 2020/04/12 Week 18 , 2020/04/27 - 2020/05/03
End of Life 2020/05/29

6.2 リリース

最初のリリースとバグ修正リリースの基本日程
バージョン 凍結 公開
6.2.0 (freeze: week 02) Week 42 , 2018/10/15 - 2018/10/21 Week 06 , 2019/02/04 - 2019/02/10
6.2.1 Week 06 , 2019/02/04 - 2019/02/10 Week 09 , 2019/02/25 - 2019/03/03
6.2.2 Week 09 , 2019/02/25 - 2019/03/03 Week 12 , 2019/03/18 - 2019/03/24
6.2.3 Week 13 , 2019/03/25 - 2019/03/31 Week 16 , 2019/04/15 - 2019/04/21
6.2.4 Week 18 , 2019/04/29 - 2019/05/05 Week 21 , 2019/05/20 - 2019/05/26
6.2.5 Week 24 , 2019/06/10 - 2019/06/16 Week 27 , 2019/07/01 - 2019/07/07
6.2.6 Week 30 , 2019/07/22 - 2019/07/28 Week 33 , 2019/08/12 - 2019/08/18
6.2.7 Week 39 , 2019/09/23 - 2019/09/29 Week 42 , 2019/10/14 - 2019/10/20
End of Life 2019/11/30

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

6.1 リリース

最初のリリースとバグ修正リリースの基本日程
バージョン 凍結 公開
6.1.0 (freeze: week 29) Week 17 , 2018/04/23 - 2018/04/29 Week 32 , 2018/08/06 - 2018/08/12
6.1.1 (initially week 35) Week 32 , 2018/08/06 - 2018/08/12 Week 37 , 2018/09/10 - 2018/09/16
6.1.2 (shortened to one rc) Week 38 , 2018/09/17 - 2018/09/23 Week 39 , 2018/09/24 - 2018/09/30
6.1.3 Week 41 , 2018/10/08 - 2018/10/14 Week 44 , 2018/10/29 - 2018/11/04
6.1.4 Week 48 , 2018/11/26 - 2018/12/02 Week 51 , 2018/12/17 - 2018/12/23
6.1.5 Week 3 , 2019/01/14 - 2019/01/20 Week 6 , 2019/02/04 - 2019/02/10
6.1.6 Week 15 , 2019/04/08 - 2019/04/14 Week 18 , 2019/04/29 - 2019/05/05
End of Life 2019/05/29

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

6.0 リリース

最初のリリースとバグ修正リリースの基本日程
バージョン 凍結 公開
6.0.0 (freeze: week 2) Week 42 , 2017/10/16 - 2017/10/22 Week 5 , 2018/01/29 - 2018/02/04
6.0.1 Week 6 , 2018/02/05 - 2018/02/11 Week 6 , 2018/02/05 - 2018/02/11
6.0.2 Week 8 , 2018/02/19 - 2018/02/25 Week 9 , 2018/02/26 - 2018/03/04
6.0.3 Week 11 , 2018/03/12 - 2018/03/18 Week 14 , 2018/04/02 - 2018/04/08
6.0.4 Week 16 , 2018/04/16 - 2018/04/22 Week 19 , 2018/05/07 - 2018/05/13
6.0.5 Week 22 , 2018/05/28 - 2018/06/03 Week 25 , 2018/06/18 - 2018/06/24
6.0.6 Week 28 , 2018/07/09 - 2018/07/15 Week 31 , 2018/07/30 - 2018/08/05
6.0.7 Week 40 , 2018/10/01 - 2018/10/07 Week 43 , 2018/10/22 - 2018/10/28
End of Life 2018/11/26

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

5.4 リリース

最初のリリースとバグ修正リリースの基本日程
バージョン 凍結 公開
5.4.0 (freeze: week 27) Week 17 , 2017/04/24 - 2017/04/30 Week 30 , 2017/07/24 - 2017/07/30
5.4.1 Week 32 , 2017/08/07 - 2017/08/13 Week 35 , 2017/08/28 - 2017/09/03
5.4.2 Week 37 , 2017/09/11 - 2017/09/17 Week 40 , 2017/10/02 - 2017/10/08
5.4.3 Week 42 , 2017/10/16 - 2017/10/22 Week 45 , 2017/11/06 - 2017/11/12
5.4.4 Week 48 , 2017/11/27 - 2017/12/03 Week 51 , 2017/12/18 - 2017/12/24
5.4.5 Week 4 , 2018/01/22 - 2018/01/28 Week 6 , 2018/02/05 - 2018/02/11
5.4.6 Week 9 , 2018/02/26 - 2018/03/04 Week 12 , 2018/03/19 - 2018/03/25
5.4.7 Week 15 , 2018/04/09 - 2018/04/15 Week 18 , 2018/04/30 - 2018/05/06
End of Life 2018/06/11

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

日時

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

リリースは、いくつかの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.