출시계획

From The Document Foundation Wiki
Jump to navigation Jump to search
This page is a translated version of the page ReleasePlan and the translation is 15% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎dansk • ‎español • ‎français • ‎italiano • ‎português do Brasil • ‎română • ‎русский • ‎עברית • ‎العربية • ‎فارسی • ‎日本語 • ‎한국어

소개

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.

  • 리브레오피스는 연 2회, 예측 가능한 출시를 합니다. 출시는 다른 무료 소프트웨어 프로젝트들(예를들면 Gnome)의 추세에 맞추어 진행됩니다. 그리고 그 출시들은 리눅스 배포출시보다 최소한 한달 먼저 진행됩니다.
  • 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.
  • 그 결과, 사용자들은 6개월마다 넓은 범위로 새로운 기능, 수정, 그리고 기능이 향상된 버전을 이용할 수 있습니다. 추가로, 순수 버그 수정에 따른 소규모 출시도 많이 이루어집니다. 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.

Note that the dates mentioned in the schedule might get shifted if there are serious technical or other problems with the release. An extra RC might be needed if the final release candidate does not fit the Release Criteria. Such problem would shift the final release by one week or even more. Template:LibOReleaseLifecycle/ko

7.2 release

Basic dates for the initial and bugfix releases
Release Freeze Publishing
7.2.0 (freeze: week 30) Week 19 , 5 10, 2021 - 5 16, 2021 Week 33 , 8 16, 2021 - 8 22, 2021
7.2.1 Week 34 , 8 23, 2021 - 8 29, 2021 Week 37 , 9 13, 2021 - 9 19, 2021
7.2.2 Week 38 , 9 20, 2021 - 9 26, 2021 Week 41 , 10 11, 2021 - 10 17, 2021
7.2.3 Week 44 , 11 1, 2021 - 11 7, 2021 Week 47 , 11 22, 2021 - 11 28, 2021
7.2.4 Week 50 , 12 13, 2021 - 12 19, 2021 Week 53 , 1 3, 2022 - 1 9, 2022
7.2.5 Week 07 , 2 14, 2022 - 2 20, 2022 Week 10 , 3 7, 2022 - 3 13, 2022
7.2.6 Week 16 , 4 18, 2022 - 4 24, 2022 Week 19 , 5 9, 2022 - 5 15, 2022
End of Life June 12, 2022

See also the detailed schedule and the release notes.


7.1 release

Basic dates for the initial and bugfix releases
Release Freeze Publishing
7.1.0 (freeze: week 02) Week 43 , 10 19, 2020 - 10 25, 2020 Week 05 , 2 1, 2021 - 2 7, 2021
7.1.1 Week 06 , 2 8, 2021 - 2 14, 2021 Week 09 , 3 1, 2021 - 3 7, 2021
7.1.2 Week 10 , 3 8, 2021 - 3 14, 2021 Week 13 , 3 29, 2021 - 4 4, 2021
7.1.3 Week 15 , 4 12, 2021 - 4 18, 2021 Week 18 , 5 3, 2021 - 5 9, 2021
7.1.4 Week 20 , 5 17, 2021 - 5 23, 2021 Week 23 , 6 7, 2021 - 6 13, 2021
7.1.5 Week 26 , 6 28, 2021 - 7 4, 2021 Week 29 , 7 19, 2021 - 7 25, 2021
7.1.6 Week 33 , 8 16, 2021 - 8 22, 2021 Week 36 , 9 6, 2021 - 9 12, 2021
7.1.7 Week 41 , 10 11, 2021 - 10 17, 2021 Week 44 , 11 1, 2021 - 11 7, 2021
End of Life November 30, 2021

See also the detailed schedule and the release notes.


7.0 release

Basic dates for the initial and bugfix releases
Release Freeze Publishing
7.0.0 (freeze: week 29) Week 19 , 5 4, 2020 - 5 10, 2020 Week 32 , 8 3, 2020 - 8 9, 2020
7.0.1 Week 33 , 8 10, 2020 - 8 16, 2020 Week 36 , 8 31, 2020 - 9 6, 2020
7.0.2 Week 38 , 9 14, 2020 - 9 20, 2020 Week 41 , 10 5, 2020 - 10 11, 2020
7.0.3 Week 43 , 10 19, 2020 - 10 25, 2020 Week 46 , 11 9, 2020 - 11 15, 2020
7.0.4 Week 48 , 11 23, 2020 - 11 29, 2020 Week 51 , 12 14, 2020 - 12 20, 2020
7.0.5 Week 07 , 2 15, 2021 - 2 21, 2021 Week 10 , 3 8, 2021 - 3 14, 2021
7.0.6 Week 16 , 4 19, 2021 - 4 25, 2021 Week 19 , 5 10, 2021 - 5 16, 2021
End of Life May 31, 2021

See also the detailed schedule and the release notes.

6.4 release

Basic dates for the initial and bugfix releases
Release Freeze Publishing
6.4.0 (freeze: week 02) Week 42 , 10 14, 2019 - 10 20, 2019 Week 05 , 1 27, 2020 - 2 2, 2020
6.4.1 Week 06 , 2 3, 2020 - 2 9, 2020 Week 09 , 2 24, 2020 - 3 1, 2020
6.4.2 Week 09 , 2 24, 2020 - 3 1, 2020 Week 12 , 3 16, 2020 - 3 22, 2020
6.4.3 Week 13 , 3 23, 2020 - 3 29, 2020 Week 16 , 4 13, 2020 - 4 19, 2020
6.4.4 Week 18 , 4 27, 2020 - 5 3, 2020 Week 21 , 5 18, 2020 - 5 24, 2020
6.4.5 Week 24 , 6 8, 2020 - 6 14, 2020 Week 27 , 6 29, 2020 - 7 5, 2020
6.4.6 Week 30 , 7 20, 2020 - 7 26, 2020 Week 33 , 8 10, 2020 - 8 16, 2020
6.4.7 Week 39 , 9 21, 2020 - 9 27, 2020 Week 42 , 10 12, 2020 - 10 18, 2020
End of Life November 30, 2020

See also the detailed schedule and the release notes.

6.3 release

Basic dates for the initial and bugfix releases
Release Freeze Publishing
6.3.0 (freeze: week 29) Week 19 , 5 6, 2019 - 5 12, 2019 Week 32 , 8 5, 2019 - 8 11, 2019
6.3.1 Week 32 , 8 5, 2019 - 8 11, 2019 Week 35 , 8 26, 2019 - 9 1, 2019
6.3.2 Week 36 , 9 2, 2019 - 9 8, 2019 Week 39 , 9 23, 2019 - 9 29, 2019
6.3.3 Week 41 , 10 7, 2019 - 10 13, 2019 Week 44 , 10 28, 2019 - 11 3, 2019
6.3.4 Week 47 , 11 18, 2019 - 11 24, 2019 Week 50 , 12 9, 2019 - 12 15, 2019
6.3.5 Week 05 , 1 27, 2020 - 2 2, 2020 Week 08 , 2 17, 2020 - 2 23, 2020
6.3.6 Week 15 , 4 6, 2020 - 4 12, 2020 Week 18 , 4 27, 2020 - 5 3, 2020
End of Life May 29, 2020

See also the detailed schedule and the release notes.

릴리즈 요일

릴리즈는 시간기반이지만 유연성을 위해서 스케쥴은 요일단위가 아니라 주(week) 단위로 이루어집니다. 릴리즈는 버그, 빌드 오류, 기술적 이슈에 의해 몇일정도 연기 될 수 있습니다.

릴리즈는 몇개의 베타버전과 릴리즈 빌드 후보군으로 이루어져있습니다. 각 빌드에 대해서 몇가지 작업이 필요합니다.

이상적인 워크플로우:

  • 월요일: 커밋 기한; reminder is sent to devel, l10n mailing list before it happens
  • 화요일: the tag is created on a commit that builds and passes unit-, subsequent-, and smoke-tests; tag is announced on the devel and qa mailing lists
  • 수요일: builds are uploaded on the early pre-release site; they are announced on the devel and qa mailing lists
  • 목요일: builds are uploaded on mirrors. They are announced via many channels, e.g. mailing lists, twitter
  • 금요일: 빌드들은 공식 사전릴리즈 사이트 에서 열람 가능합니다.

최종 릴리즈는 주로 최종 릴리즈 후보가 나오고 며칠 뒤인 목요일에 공지됩니다.

Note that we are very strict about commits to the final release candidate, so full regression test is not needed. It is used as the final build when it passes the needed tests. It is just renamed on mirrors.

스케쥴

스케쥴은 아래와 같은 규칙을 준수합니다:

  • do the major release every six months and synchronize it (at least one month ahead) with major Linux distributions; it always comes with a wide range of features, fixes, and enhancements
  • do a pure bugfix release every month after the main release until it is good enough even for the most conservative people; do it less frequently afterwards
  • do pure bugfix releases, including security fixes, until the next release is ready for most conservative people
  • do not do two builds the same week.

결과는 아래 템플릿을 따릅니다:

Interlocking releases
Event Summer Winter
x.y feature freeze 6월(초) 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)

(초)는 해당 월 초, (중)은 해당 월 중순, (말)은 해당 월 말을 의미합니다.

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 - Zth alpha version of the initial release
  • X.Y.0.0.betaZ - Zth beta version of the initial release
  • 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.

End-of-Life Releases

A release normally has a lifetime of around nine months. We consider a release to have reached its End of Life (EOL) one month after the last planned release.

If you want longer term support for a release, you’re encouraged to engage any certified L3 provider who could provide you with the service.

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