Планы релизов
TDF LibreOffice Document Liberation Project Блоги сообщества Weblate Nextcloud Redmine Ask LibreOffice Пожертвования
Введение
Выход версий LibreOffice основан на заранее оговорённых датах, что позволяет получить максимально качественный результат, при условии получения конечным пользователем большого количества новых возможностей. В таких выходах версий не устанавливается цель достижение каких-либо существенных изменений или устранение всех возможных ошибок, а (по возможности) выход в определённое время. Это позволяет достичь дисциплины для разработчиков, создаёт предсказуемость и позволяет получать более регулярные выпуски. Высвобождая первую версию в ветке, начинается активная работа по устранению возможных не исправленных ошибок. Таким образом, если у вас есть необходимость в очень высоком качестве, имеет смысл отложить переход на новую версию до первого или, возможно, второго выпуска обновлений, в которых разработчики пытаются убрать все обнаруженные после выхода ошибки.
- LibreOffice выпускает предсказуемые выпуски раз в два года, которые синхронизируются с другими проектами свободного ПО (например, Gnome) и как минимум на месяц опережают основные выпуски дистрибутивов Linux.
- Синхронизация расписания выпусков с более широкой экосистемой свободного программного обеспечения также имеет огромные преимущества, поскольку наши новые функции доводятся до пользователей как можно быстрее — с минимальной задержкой цикла распространения. Как следствие, мы стремимся к шести ежемесячным выпускам и со временем подталкиваем их, чтобы они соответствовали нормам марта/сентября.
- Существует 2 ветки: Fresh (новейшая версия) и Still (предыдущая версия), которые предназначены для основных пользователей и консервативных корпоративных развертываний соответственно.
- В результате каждые шесть месяцев пользователи получают новую основную версию с широким набором функций, исправлений и улучшений. Кроме того, они получают много микро-выпусков с исправлениями ошибок. Первый выпуск X.Y.0 предназначен для ранних пользователей. Более консервативным пользователям рекомендуется дождаться более позднего выпуска исправления ошибок X.Y.Z.
Обратите внимание, что даты, указанные в расписании, могут быть сдвинуты, если с релизом возникнут серьезные технические или иные проблемы. Дополнительный RC может потребоваться, если окончательный кандидат на выпуск не соответствует Критериям выпуска. Такая проблема сдвинула бы финальный релиз на одну неделю или даже больше.
На упрощенном графике ниже показаны три выпуска, размещенные на временной шкале, состоящей из 24 месяцев.
24.2 release
| Release | Freeze | Publishing |
|---|---|---|
| 24.2.0 (freeze: week 02) | Неделя 47 , 20.11.2023 - 26.11.2023 | Неделя 05 , 29.1.2024 - 4.2.2024 |
| 24.2.1 | Неделя 06 , 5.2.2024 - 11.2.2024 | Неделя 09 , 26.2.2024 - 3.3.2024 |
| 24.2.2 | Неделя 10 , 4.3.2024 - 10.3.2024 | Неделя 13 , 25.3.2024 - 31.3.2024 |
| 24.2.3 | Неделя 15 , 8.4.2024 - 14.4.2024 | Неделя 18 , 29.4.2024 - 5.5.2024 |
| 24.2.4 | Неделя 20 , 13.5.2024 - 19.5.2024 | Неделя 23 , 3.6.2024 - 9.6.2024 |
| 24.2.5 | Неделя 26 , 24.6.2024 - 30.6.2024 | Неделя 29 , 15.7.2024 - 21.7.2024 |
| 24.2.6 | Неделя 33 , 12.8.2024 - 18.8.2024 | Неделя 36 , 2.9.2024 - 8.9.2024 |
| 24.2.7 | Неделя 41 , 7.10.2024 - 13.10.2024 | Неделя 44 , 28.10.2024 - 3.11.2024 |
| End of Life | November 30, 2024 | |
See also the detailed schedule and the release notes.
7.6 release
| Release | Freeze | Publishing |
|---|---|---|
| 7.6.0 (freeze: week 30) | Неделя 19 , 8.5.2023 - 14.5.2023 | Неделя 34 , 21.8.2023 - 27.8.2023 |
| 7.6.1 | Неделя 34 , 21.8.2023 - 27.8.2023 | Неделя 37 , 11.9.2023 - 17.9.2023 |
| 7.6.2 | Неделя 38 , 18.9.2023 - 24.9.2023 | Неделя 39 , 25.9.2023 - 1.10.2023 |
| 7.6.3 | Неделя 44 , 30.10.2023 - 5.11.2023 | Неделя 47 , 20.11.2023 - 26.11.2023 |
| 7.6.4 | Неделя 50 , 11.12.2023 - 17.12.2023 | Неделя 53 , 1.1.2024 - 7.1.2024 |
| 7.6.5 | Неделя 05 , 29.1.2024 - 4.2.2024 | Неделя 08 , 19.2.2024 - 25.2.2024 |
| 7.6.6 | Неделя 10 , 4.3.2024 - 10.3.2024 | Неделя 13 , 25.3.2024 - 31.3.2024 |
| 7.6.7 | Неделя 16 , 15.4.2024 - 21.4.2024 | Неделя 19 , 6.5.2024 - 12.5.2024 |
| End of Life | June 12, 2024 | |
See also the detailed schedule and the release notes.
Версия 7.5
| Версия | Заморозка | Публикация |
|---|---|---|
| 7.5.0 (заморозка: неделя 02) | Неделя 47 , 21.11.2022 - 27.11.2022 | Неделя 05 , 30.1.2023 - 5.2.2023 |
| 7.5.1 | Неделя 06 , 6.2.2023 - 12.2.2023 | Неделя 09 , 27.2.2023 - 5.3.2023 |
| 7.5.2 | Неделя 10 , 6.3.2023 - 12.3.2023 | Неделя 13 , 27.3.2023 - 2.4.2023 |
| 7.5.3 | Неделя 15 , 10.4.2023 - 16.4.2023 | Неделя 18 , 1.5.2023 - 7.5.2023 |
| 7.5.4 | Неделя 20 , 15.5.2023 - 21.5.2023 | Неделя 23 , 5.6.2023 - 11.6.2023 |
| 7.5.5 | Неделя 26 , 26.6.2023 - 2.7.2023 | Неделя 29 , 17.7.2023 - 23.7.2023 |
| 7.5.6 | Неделя 33 , 14.8.2023 - 20.8.2023 | Неделя 36 , 4.9.2023 - 10.9.2023 |
| 7.5.7 | Неделя 38 , 18.9.2023 - 24.9.2023 | Неделя 39 , 25.9.2023 - 1.10.2023 |
| 7.5.8 | Неделя 41 , 9.10.2023 - 15.10.2023 | Неделя 44 , 30.10.2023 - 5.11.2023 |
| Конец срока службы | 30 ноября 2023 г. | |
Смотрите также подробный план и примечания к выпуску.
Даты
Выпуск новых версий основан на времени, но график определяется календарными неделями вместо точных дат. Это происходит из-за необходимой гибкости. Выпуск может быть отложен на несколько дней из-за серьёзных ошибок, проблемами со сборкой или других технических проблем.
Выпуск состоит из нескольких бета-версий и релиз-кандидатов. Существует несколько необходимых действий для каждой сборки. Идеальный ход работы выглядит так:
- Понедельник - Подтверждается срок выхода. Посылается письмо в рассылки разработчиков и групп локализации.
- Вторник - создаётся тег (присваивается номер версии в гит) который говорит о том, что пройдены тест на общую работоспособность, низкоуровневые тесты и тесты на функциональность и доступны сборки; команды разработчиков и контроля качества извещаются о теге через почтовую рассылку.
- Среда - сборки загружается вначале на сайт предварительных версий; о них сообщается в рассылке разработчиков и команды контроля качества.
- Четверг - сборки загружаются на зеркала.
- Пятница - сборки доступна на сайте официальных предварительных версий; они объявлены через многие каналы связи (например, почтовую рассылку, 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) - 'в конце месяца' соответственно.
Заморозка строки
В планах выпуска первой версии каждого основного выпуска указано "жесткая заморозка английских строк и пользовательского интерфейса". Идея состоит в том, чтобы облегчить жизнь переводчикам. Переводчики должны быть уверены, что никакие новые переводимые строки не добавляются в пользовательский интерфейс или файлы справки между периодом замораживания строки и выпуском.
In practice, you should keep an eye on the tagging of the first release candidate. One way to find out, if RC1 has been tagged is to visit the tag view of the LibreOffice core repository in Gerrit and input into the filter field: libreoffice-X.Y.Z. If the results do not contain any entry for libreoffice-X.Y.Z.1, RC1 has not yet been tagged and string changes can still be committed.
После выхода первой версии основного выпуска исправление ошибок в пользовательском интерфейсе и строках справки — это нормально. Любой совершенно новый контент должен быть нацелен на следующий основной выпуск.
Схема версий
Делается несколько сборок каждой версии, используя следующую схему:
- 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 месяцев. Мы полагаем, что через один месяц после выхода последней запланированной версии ветви она достигнет окончания своей жизни.
Если вы хотите более долгой поддержки для версии, вы можете привлечь любого сертифицированного поставщика предоставляющего услуги поддержки.
Из-за большого количества данных выпуски были разделены на ReleasePlan/Archive.