Планы релизов

From The Document Foundation Wiki
Jump to: navigation, search
This page is a translated version of the page ReleasePlan and the translation is 80% complete.

Other languages:
العربية • ‎Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎日本語 • ‎português do Brasil • ‎română • ‎русский • ‎中文(简体)‎

Введение

Выход версий LibreOffice основан на заранее оговорённых датах, что позволяет получить максимально качественный результат, при условии получения конечным пользователем большого количества новых возможностей. В таких выходах версий не устанавливается цель достижение каких-либо существенных изменений или устранение всех возможных ошибок, а (по возможности) выход в определённое время. Это позволяет достичь дисциплины для разработчиков, создаёт предсказуемость и позволяет получать более регулярные выпуски. Высвобождая первую версию в ветке, начинается активная работа по устранению возможных не исправленных ошибок. Таким образом, если у вас есть необходимость в очень высоком качестве, имеет смысл отложить переход на новую версию до первого или, возможно, второго выпуска обновлений, в которых разработчики пытаются убрать все обнаруженные после выхода ошибки.

  • 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.

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.

Версия 7.0

Основные даты релизов
номер версии дата стабилизации кода дата выпуска
7.0.0 (freeze: week 29) Неделя 19 , 4.5.2020 - 10.5.2020 Неделя 32 , 3.8.2020 - 9.8.2020
7.0.1 Неделя 33 , 10.8.2020 - 16.8.2020 Неделя 36 , 31.8.2020 - 6.9.2020
7.0.2 Неделя 38 , 14.9.2020 - 20.9.2020 Неделя 41 , 5.10.2020 - 11.10.2020
7.0.3 Неделя 43 , 19.10.2020 - 25.10.2020 Неделя 46 , 9.11.2020 - 15.11.2020
7.0.4 Неделя 48 , 23.11.2020 - 29.11.2020 Неделя 51 , 14.12.2020 - 20.12.2020
7.0.5 Неделя 06 , 8.2.2021 - 14.2.2021 Неделя 09 , 1.3.2021 - 7.3.2021
7.0.6 Неделя 15 , 12.4.2021 - 18.4.2021 Неделя 18 , 3.5.2021 - 9.5.2021
End of Life May 31, 2021

См. также Подробный план и Примечания к выпуску.

Версия 6.4

Основные даты релизов
номер версии дата стабилизации кода дата выпуска
6.4.0 (freeze: week 02) Неделя 42 , 14.10.2019 - 20.10.2019 Неделя 05 , 27.1.2020 - 2.2.2020
6.4.1 Неделя 06 , 3.2.2020 - 9.2.2020 Неделя 09 , 24.2.2020 - 1.3.2020
6.4.2 Неделя 09 , 24.2.2020 - 1.3.2020 Неделя 12 , 16.3.2020 - 22.3.2020
6.4.3 Неделя 13 , 23.3.2020 - 29.3.2020 Неделя 16 , 13.4.2020 - 19.4.2020
6.4.4 Неделя 18 , 27.4.2020 - 3.5.2020 Неделя 21 , 18.5.2020 - 24.5.2020
6.4.5 Неделя 24 , 8.6.2020 - 14.6.2020 Неделя 27 , 29.6.2020 - 5.7.2020
6.4.6 Неделя 30 , 20.7.2020 - 26.7.2020 Неделя 33 , 10.8.2020 - 16.8.2020
6.4.7 Неделя 39 , 21.9.2020 - 27.9.2020 Неделя 42 , 12.10.2020 - 18.10.2020
End of Life November 30, 2020

См. также Подробный план и Примечания к выпуску.

Версия 6.3

Основные даты релизов
номер версии дата стабилизации кода дата выпуска
6.3.0 (freeze: week 29) Неделя 19 , 6.5.2019 - 12.5.2019 Неделя 32 , 5.8.2019 - 11.8.2019
6.3.1 Неделя 32 , 5.8.2019 - 11.8.2019 Неделя 35 , 26.8.2019 - 1.9.2019
6.3.2 Неделя 36 , 2.9.2019 - 8.9.2019 Неделя 39 , 23.9.2019 - 29.9.2019
6.3.3 Неделя 41 , 7.10.2019 - 13.10.2019 Неделя 44 , 28.10.2019 - 3.11.2019
6.3.4 Неделя 47 , 18.11.2019 - 24.11.2019 Неделя 50 , 9.12.2019 - 15.12.2019
6.3.5 Неделя 05 , 27.1.2020 - 2.2.2020 Неделя 08 , 17.2.2020 - 23.2.2020
6.3.6 Неделя 15 , 6.4.2020 - 12.4.2020 Неделя 18 , 27.4.2020 - 3.5.2020
End of Life May 29, 2020

См. также Подробный план и Примечания к выпуску.

Даты

Выпуск новых версий основан на времени, но график определяется календарными неделями вместо точных дат. Это происходит из-за необходимой гибкости. Выпуск может быть отложен на несколько дней из-за серьёзных ошибок, проблемами со сборкой или других технических проблем.

Выпуск состоит из нескольких бета-версий и релиз-кандидатов. Существует несколько необходимых действий для каждой сборки. Идеальный ход работы выглядит так:

  • Понедельник - Подтверждается срок выхода. Посылается письмо в рассылки разработчиков и групп локализации.
  • Вторник - создаётся тег (присваивается номер версии в гит) который говорит о том, что пройдены тест на общую работоспособность, низкоуровневые тесты и тесты на функциональность и доступны сборки; команды разработчиков и контроля качества извещаются о теге через почтовую рассылку.
  • Среда - сборки загружается вначале на сайт предварительных версий; о них сообщается в рассылке разработчиков и команды контроля качества.
  • Четверг - сборки загружаются на зеркала.
  • Пятница - сборки доступна на сайте официальных предварительных версий; они объявлены через многие каналы связи (например, почтовую рассылку, twitter)

О выпуске новой версии обычно объявляют в среду, через несколько дней после того как выпущен окончательный релиз-кандидат.

Обратите внимание, что мы достаточно требовательны и относимся серьёзно в отношении релиз-кандидата, поэтому полный тест регрессии не требуется. Он используется в качестве окончательной сборки, когда проходит все необходимые тесты. И просто переименовывается на зеркалах.

Расписание

План выпуска составляется с учётом следующих правил:

  • Выпускать основную ветку каждые шесть месяцев, даты скорректированы в соответствии с датами выпуска популярных Linux-дистрибутивов. Он всегда поставляется с широким набором функций, исправлений и усовершенствований.
  • После того, как была выпущена основная версия, выпускать каждый месяц версию с исправлениями найденных ошибок. Выпускать до тех пор, пока даже самые консервативные люди не захотят сменить офисный пакет на новую версию. Выпускать версию с исправлениями найденных ошибок менее часто после начала массового перехода на новую версию офисного пакета.
  • Выпускать версию с исправлениями найденных ошибок, в том числе ошибок безопасности, до тех пор, пока для самых консервативных клиентов не будет готова новая версия пакета.
  • Не делать две сборки на одной и той же неделе.

Результатом является следующий шаблон дат выпуска:

Взаимосвязь релизов
событие лето зима
x.y заморозка кода Январь(b) Декабрь(b)
x.y.0 релиз Август(b) Февраль(b)
x.y.1 релиз Сентябрь(b) Март(b)
x.y.2 релиз Октябрь(b) Апрель(b)
x.y.3 релиз Ноябрь(b) Май(b)
x.y.4 релиз Декабрь(b) Январь(b)
x.y.5 релиз Февраль(m) Август(m)
x.y.6 релиз Апрель(m) Октябрь(m)

, где (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.

Схема версий

Делается несколько сборок каждой версии, используя следующую схему:

  • X.Y.0.0.alphaZ - Z-ая альфа-версия первого выпуска.
  • X.Y.0.0.betaZ - Z-ая бета-версия первого выпуска.
  • X.Y.0.Z - Z-ый релиз-кандидат первого выпуска, последний релиз-кондидат считается новой версией и помещается на страницы загрузки
  • X.Y.1.Z - Z-ый релиз-кандидат первого выпуска с исправлениями найденных ошибок, последний релиз-кондидат считается новой версией и помещается на страницы загрузки

Очевидно, что это лучший компромисс со следующими преимуществами:

  • Легко понимаем обычными пользователями - версии альфа и бета известны из других проектов, поэтому создают разумные ожидания.
  • Правильная алфавитная сортировка в RPM, Bugzilla.
  • Легко разбирать (подстроки разделены точкой).

В своё время была дискуссия об этой схеме в рассылке.

Ускорение в цикле выпуска

Ускорение в цикле выпуска включает в себя некоторые существенные усилия разработчиков и команды контроля качества (QA). Чтобы уменьшить их затраты, делаются ежедневные полные сборки кода (т.е. включающие все поддерживаемые языки). Это позволяет сделать процесс тестирования улучшений и исправления ошибок непрерывным. Эта работа частично уже делается, посмотреть/скачать ежедневные сборки можно тут.

Так же, планируется сделать процесс сборки более автоматизированным, чтобы в дальнейшем меньше касаться процесса и обеспечить более быструю передачу конечного продукта.

Релизы с истекшим сроком поддержки

Обычно жизненный срок ветви 9 месяцев. Мы полагаем, что через один месяц после выхода последней запланированной версии ветви она достигнет окончания своей жизни.

Если вы хотите более долгой поддержки для версии, вы можете привлечь любого сертифицированного поставщика предоставляющего услуги поддержки.

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