ReleasePlan/ru

Введение
Выход версий 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.

The simplified graphic below shows three releases placed on a timeline consisting of 24 months.

Future Fresh Still

7.4 release
See also the detailed schedule and the release notes.

7.3 release
See also the detailed schedule and the release notes.

7.2 release
See also the detailed schedule and the release notes.

7.1 release
See also the detailed schedule and the release notes.

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

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

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

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

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


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

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

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

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


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

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

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