Процесс выпуска Wagtail

Официальные релизы

Нумерация релизов работает следующим образом:

Версии пронумерованы в формате A.B или A.B.C.
A.B — это номер версии релиза с новыми функциями. Каждая версия будет в основном совместима с предыдущим релизом. Исключение из этого правила будут указаны в примечаниях к релизу.
C — это номер версии исправительного релиза, который увеличивается для исправлений ошибок и проблем безопасности. Эти релизы будут на 100% совместимы с предыдущим исправительным релизом. Исключением является случай, когда проблему безопасности или потери данных невозможно исправить без нарушения обратной совместимости. В этом случае примечания к релизу содержат подробные инструкции по обновлению.
Перед новым релизом с новыми функциями мы создадим, как минимум, одну предварительную версию релиза. Эти версии имеют формат A.BrcN, что означает предварительную версию Nth релиза версии A.B.

В системе контроля версий Git каждый релиз Wagtail будет иметь тег, указывающий его номер версии. Кроме того, каждый ряд релизов имеет свою ветку, называемую stable/A.B.x, и исправительные/безопасные релизы будут выпущены из этих веток.

Режим выпуска

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

Политика устаревания

Релиз с новыми функциями может устареть некоторые функции предыдущих релизов. Если функция устарела в релизе A.B, она продолжит работать в следующей версии, но будет выводить предупреждения. Функции, устаревшие в релизе A.B, будут удалены в релизе A.B+2, чтобы гарантировать, что устаревание происходит не менее чем за 2 релиза с новыми функциями.

Например, если мы решили начать устаревание функции в Wagtail 1.4:

Wagtail 1.4 будет содержать обратную совместимую копию функции, которая будет генерировать RemovedInWagtail16Warning.
Wagtail 1.5 по-прежнему будет содержать обратную совместимую копию.
Wagtail 1.6 удалит эту функцию.

Предупреждения по умолчанию не отображаются. Вы можете включить отображение этих предупреждений с помощью опции python -Wd.

Поддерживаемые версии

В любой момент времени команда разработчиков Wagtail поддерживает ряд релизов на разных уровнях.

Текущая main ветка разработки будет получать новые функции и исправления ошибок, требующие нетривиальной рефакторизации.
Исправления, внесенные в ветку main , также должны быть применены к последней ветке с новыми функциями, чтобы быть выпущенными в следующем исправительном релизе этой серии функций, когда они исправляют критические проблемы:
- Проблемы безопасности.
- Ошибки потери данных.
- Ошибки аварийного завершения.
- Серьезные ошибки функционирования новых функций.
- Регрессии из более ранних версий Wagtail.
Правило thumb заключается в том, что исправления будут обратно перенесены в последнюю ветку с новыми функциями для ошибок, которые могли бы предотвратить выпуск в первую очередь (блокирующие выпуск).
Исправления ошибок безопасности и потери данных будут применяться к текущей main, последней ветке с новыми функциями и любым другим поддерживаемым долгосрочным веткам поддержки.
Исправления документации, как правило, будут более свободно обратно перенесены в последнюю ветку релиза. Это связано с тем, что крайне важно, чтобы документация последнего релиза была актуальной и корректной, а риск введения регрессий значительно меньше.

Рассмотрим пример, когда в момент времени находится между выпуском Wagtail 1.6 и 1.7. В этот момент времени:

Функции будут добавлены в main, чтобы быть выпущенными как Wagtail 1.7.
Критические исправления ошибок будут применены к ветке stable/1.6.x, и выпущены как 1.6.1, 1.6.2 и т.д.
Исправления ошибок безопасности и потери данных будут применены к main и к веткам stable/1.6.x и stable/1.4.x (LTS). Они вызовут выпуск 1.6.1, 1.4.8 и т.д.
Исправления документации будут применены к main, и, если это легко обратно перенести, к последней стабильной ветке, 1.6.x.

Поддерживаемые версии Django

Каждый релиз Wagtail объявляет, какие версии Django он поддерживает.

Как правило, новый релиз Wagtail с новыми функциями поддерживает последнюю долгосрочную поддерживаемую версию и все последующие версии Django.

Например, рассмотрим момент времени перед выпуском Wagtail 1.5 и после следующих релизов:

Django 1.8 (LTS)
Django 1.9
Wagtail 1.4 (LTS) - Выпущен до Django 1.10 и поддерживает Django 1.8 и 1.9
Django 1.10

Wagtail 1.5 будет поддерживать Django 1.8 (LTS), 1.9 и 1.10. Wagtail 1.4 по-прежнему будет поддерживать только Django 1.8 (LTS) и 1.9.

Процесс выпуска

Wagtail использует график выпуска на основе времени, с выпуском новых функций каждые три месяца.

После каждого выпуска с новыми функциями менеджер выпуска объявит график для следующего выпуска с новыми функциями.

Цикл выпуска

Каждый цикл выпуска состоит из трех частей:

Фаза первая: предложение функций

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

Фаза вторая: разработка

Вторая часть графика выпуска — это период «работы в одиночку». Используя дорожную карту, составленную в конце первой фазы, мы все будем очень усердно работать, чтобы выполнить все поставленные задачи.

В конце второй фазы все незавершенные функции будут отложены до следующего релиза.

В этот момент ветка stable/A.B.x будет сгенерирована из ветки main.

Фаза третья: исправление ошибок

Последняя часть цикла выпуска посвящена исправлению ошибок — новые функции не будут приниматься в течение этого времени.

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

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

Разработчики должны избегать добавления новых переводимых строк после предварительной версии релиза — это гарантирует, что у переводчиков есть весь период между предварительной версией релиза и окончательной версией, чтобы привести переводы к актуальному состоянию. Переводы будут повторно импортированы непосредственно перед окончательным релизом.

Параллельно с этой фазой main может получать новые функции, чтобы быть выпущенными в цикле A.B+1.

Релизы с исправлениями ошибок

После релиза с новыми функциями (например, A.B), предыдущий релиз переходит в режим исправления ошибок.

Ветка для предыдущего релиза с новыми функциями (например, stable/A.B-1.x) будет включать исправления ошибок. Критические ошибки, исправленные в main, также должны быть исправлены в ветке исправления ошибок; это означает, что коммиты должны четко разделять исправления ошибок и добавления функций. Разработчик, который внес исправление в main, будет нести ответственность за применение этого исправления также к текущей ветке исправления ошибок.