Процесс выпуска Django ¶
Официальные релизы ¶
Начиная с версии 1.0, нумерация выпусков Django работает следующим образом:
- Версии нумеруются в форме
A.B
илиA.B.C
. A.B
- номер версии выпуска функции . Каждая версия будет в основном обратно совместима с предыдущим выпуском. Исключения из этого правила будут перечислены в примечаниях к выпуску.C
- это номер версии выпуска исправления , который увеличивается для исправлений ошибок и выпусков безопасности. Эти выпуски будут на 100% обратно совместимы с предыдущим выпуском исправлений. Единственное исключение - когда проблема безопасности или потери данных не может быть устранена без нарушения обратной совместимости. Если это произойдет, в примечаниях к выпуску будут представлены подробные инструкции по обновлению.- Перед выпуском новой функции мы сделаем альфа-, бета-версии и выпуски-кандидаты. Они имеют форму , которая означает
альфа / бета / релиз-кандидат версии .
A.B alpha/beta/rc N
Nth
A.B
В git каждый выпуск Django будет иметь тег, указывающий его номер версии, подписанный ключом выпуска Django. Кроме того, каждая серия выпусков имеет свою собственную ветку, называемую stable/A.B.x
, и выпуски исправлений / безопасности выпускаются из этих веток.
Для получения дополнительной информации о том, как проект Django выпускает новые выпуски в целях безопасности, ознакомьтесь с нашими политиками безопасности .
- Выпуск функции
- Релизы функций (AB, A.B + 1 и т. Д.) Будут происходить примерно каждые восемь месяцев - подробности см. В процессе выпуска . Эти выпуски будут содержать новые функции, улучшения существующих функций и т. Д.
- Выпуск патча
Выпуски исправлений (ABC, ABC + 1 и т. Д.) Будут выпускаться по мере необходимости для исправления ошибок и / или проблем с безопасностью.
Эти выпуски будут на 100% совместимы с соответствующим выпуском функций, если это невозможно по соображениям безопасности или для предотвращения потери данных. Итак, ответ на вопрос «следует ли мне обновиться до последней версии патча?» всегда будет «да».
- Выпуск долгосрочной поддержки
Некоторые выпуски функций будут обозначены как выпуски с долгосрочной поддержкой (LTS). Эти выпуски будут получать исправления безопасности и потери данных, применяемые в течение гарантированного периода времени, обычно три года.
См. Страницу загрузки для выпусков, которые предназначены для долгосрочной поддержки.
Темп выпуска ¶
Начиная с Django 2.0, номера версий будут использовать свободную форму семантического управления версиями , так что каждая версия, следующая за LTS, будет переходить к следующей версии с нулевой точкой. Например: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS) и т. Д.
SemVer позволяет сразу увидеть, насколько релизы совместимы друг с другом. Это также помогает предвидеть, когда будут удалены прокладки совместимости. Это не чистая форма SemVer, поскольку каждый выпуск функции будет по-прежнему иметь несколько задокументированных обратных несовместимостей, когда отказ от поддержки невозможен или не стоит затрат. Кроме того, устаревание, начатое в выпуске LTS (X.2), будет удалено в выпуске без точки и нуля (Y.1) в соответствии с нашей политикой сохранения прокладок устаревания как минимум для двух выпусков функций. Читайте пример в следующем разделе.
Политика устаревания ¶
В выпуске функций могут быть исключены некоторые функции из предыдущих выпусков. Если функция устарела в выпуске функции Ax, она продолжит работать во всех версиях Ax (для всех версий x), но вызовет предупреждения. Устаревшие функции будут удалены в выпуске B.0 или B.1 для функций, устаревших в последнем выпуске функций Ax, чтобы гарантировать, что устаревание будет выполнено как минимум в двух выпусках функций.
Так, например, если мы решили начать устаревание функции в Django 4.2:
- Django 4.2 будет содержать обратно совместимую копию функции, которая вызовет расширение
RemovedInDjango51Warning
. - Django 5.0 (версия после 4.2) по-прежнему будет содержать обратно совместимую реплику.
- Django 5.1 полностью удалит эту функцию.
По умолчанию предупреждения не выводятся. Вы можете включить отображение этих предупреждений с помощью опции.python -Wd
Более общий пример:
- X.0
- X.1
- X.2 LTS
- Y.0: Удалите устаревшие прокладки, добавленные в X.0 и X.1.
- Y.1: Удалите устаревшие прокладки, добавленные в X.2.
- Y.2 LTS: не удаляются устаревшие прокладки (хотя Y.0 больше не поддерживается, сторонние приложения должны поддерживать совместимость с X.2 LTS, чтобы упростить обновление LTS до LTS).
- Z.0: Удаление устаревших прокладок добавлено в Y.0 и Y.1.
См. Также Руководство по прекращению поддержки функций .
Поддерживаемые версии ¶
В любой момент команда разработчиков Django поддержит набор релизов разного уровня. См. Раздел поддерживаемых версий на странице загрузки, чтобы узнать о текущем состоянии поддержки для каждой версии.
Текущая ветка разработки
main
получит новые функции и исправления ошибок, требующие нетривиального рефакторинга.Патчи, примененные к основной ветке, также должны быть применены к последней ветке выпуска функций, которые будут выпущены в следующем выпуске исправлений этой серии функций, когда они исправят критические проблемы:
- Проблемы с безопасностью.
- Ошибки потери данных.
- Сбойные ошибки.
- Основные функциональные ошибки в новых функциях последнего стабильного выпуска.
- Отклонения от старых версий Django, представленных в текущей серии выпусков.
Эмпирическое правило состоит в том, что исправления будут перенесены в последний выпуск функции для ошибок, которые изначально препятствовали выпуску (блокировщики выпуска).
Исправления безопасности и ошибки потери данных будут применены к текущей основной ветке, двум последним ветвям выпуска функций и любым другим поддерживаемым ветвям выпусков долгосрочной поддержки.
Исправления документации обычно более свободно переносятся в последнюю ветку выпуска. Это потому, что очень выгодно иметь актуальную и правильную документацию для последнего выпуска, а риск введения регрессии вызывает гораздо меньше беспокойства.
В качестве конкретного примера рассмотрим момент на полпути между выпуском Django 5.1 и 5.2. На данный момент:
- Функции будут добавлены в основную ветку разработки, которая будет выпущена как Django 5.2.
- Критические исправления ошибок будут применены к
stable/5.1.x
ветке и выпущены как 5.1.1, 5.1.2 и т. Д. - Исправления безопасности и исправление ошибок для проблем потери данных будут применяться к
main
и кstable/5.1.x
,stable/5.0.x
иstable/4.2.x
ветвям (LTS). Они будут вызывать высвобождение5.1.1
,5.0.5
,4.2.8
и т.д. - Исправления документации будут применены к основным файлам и, если их легко перенести, к последней стабильной ветке
5.1.x
.
Процесс выпуска ¶
Django использует график выпусков, основанный на времени, с выпуском функций каждые восемь месяцев или около того.
После каждого выпуска функции менеджер выпуска объявляет график следующего выпуска функции.
Цикл выпуска ¶
Каждый цикл выпуска состоит из трех частей:
Этап первый: предложение функции ¶
Первый этап процесса выпуска будет включать выяснение того, какие основные функции включить в следующую версию. Это должно включать в себя большую предварительную работу над этими функциями - рабочий код важнее грандиозного дизайна.
Основные функции для предстоящего выпуска будут добавлены на страницу дорожной карты вики, например https://code.djangoproject.com/wiki/Version1.11Roadmap .
Фаза вторая: разработка ¶
Вторая часть графика релизов - это период работы «без головы». Используя дорожную карту, созданную в конце первого этапа, мы все будем очень много работать, чтобы все на ней сделать.
В конце второго этапа любые незавершенные функции будут отложены до следующего выпуска.
Вторая фаза завершится выпуском альфа-версии. На этом этапе
stable/A.B.x
ветвь будет разветвлена main
.
Этап третий: исправления ¶
Последняя часть цикла выпуска посвящена исправлению ошибок - в течение этого времени новые функции не принимаются. Мы постараемся выпустить бета-версию через месяц после альфа и релиз-кандидата через месяц после нее.
Релиз-кандидат отмечает замораживание строки, и это происходит как минимум за две недели до финального релиза. После этого нельзя добавлять новые переводимые строки.
На этом этапе коммиттеры будут все более и более консервативными в отношении бэкпортов, чтобы избежать регрессии. После релиз-кандидата следует переносить только блокировщики релизов и исправления документации.
Параллельно с этим этапом main
могут появиться новые функции, которые будут выпущены в A.B+1
цикле.
Релизы с исправлениями ошибок ¶
После выпуска функции (например, AB) предыдущий выпуск перейдет в режим исправления ошибок.
Ветвь для предыдущего выпуска функций (например stable/A.B-1.x
) будет включать исправления. Критические ошибки, исправленные на main, также должны быть исправлены в ветке bugfix; это означает, что коммитам необходимо четко отделить исправления ошибок от дополнений функций. Разработчик, который фиксирует исправление в main, также будет нести ответственность за применение исправления к текущей ветке исправления.