Процесс публикации Django ¶
Официальные публикации ¶
Начиная с версии 1.0, нумерация версий Django работает следующим образом:
- Версии нумеруются в форме
A.B
илиA.B.C
. A.B
- это номер основной версии выпуска . Каждая версия максимально обратно совместима с предыдущей версией. Исключения из этого правила перечислены в примечаниях к выпуску.C
- это номер версии патча , который увеличивается для исправлений ошибок и безопасности. Эти публикации на 100% обратно совместимы с предыдущими выпусками исправлений. Единственное исключение - когда проблема безопасности или потери данных не может быть решена без нарушения обратной совместимости. Если это произойдет, в примечаниях к выпуску содержатся подробные инструкции по обновлению.- Перед выпуском нового основного выпуска публикуются сообщения об альфа-, бета-тестировании и обзорах. Они пронумерованы в форме , что означает альфа / бета / пробная версия .
A.B alpha/beta/rc N
Nième
A.B
В git каждая версия Django имеет «тег», названный в честь номера версии, подписанный ключом выпуска Django. Кроме того, каждая серия выпуска имеет свою ветвь, которая называется stable/A.B.x
и публикация исправления ошибок или уязвимости безопасности производится из этих отраслей.
Для получения дополнительной информации о том, как проект Django создает новые сообщения в целях безопасности, см. Наши политики безопасности .
- Основная публикация
- Основные публикации (AB, A.B + 1 и т. Д.) Выходят примерно каждые восемь месяцев, подробности см. В процессе публикации . Эти публикации содержат, среди прочего, новые функции, а также улучшения существующих.
- Корректирующая публикация
При необходимости распространяются корректирующие публикации (ABC, ABC + 1 и т. Д.) Для исправления аномалий или проблем с безопасностью.
Эти сообщения на 100% совместимы с основной версией, которой они соответствуют, если это невозможно из-за проблем с безопасностью или потери данных. Итак, ответ на вопрос «стоит ли мне обновляться до последней версии патча?» Всегда «да».
- Издание с длительным уходом
Некоторые основные выпуски обозначены как версии с долгосрочной поддержкой (LTS). Они получат исправления безопасности и потери данных в течение гарантированного периода времени, обычно три года.
См. Страницу загрузки для публикаций, обозначенных как Долгосрочная поддержка.
Скорость публикации ¶
Начиная с версии 2.0, номера версий используют свободную форму семантического управления версиями, так что каждая версия, следующая за LTS, начинается с следующей версии «нулевой точки». Например: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS) и т. Д.
SemVer позволяет легко определить совместимость версий друг с другом. Это также помогает предвидеть, когда будут удалены блоки совместимости. Это не чистая форма SemVer, так как каждый основной выпуск по-прежнему имеет несколько задокументированных несовместимостей, когда путь к устареванию невозможен или стоимость будет слишком высокой. Кроме того, устаревание, начатое во время версии LTS (X.2), удаляется в версии, отличной от .0 (Y.1), в соответствии с нашей политикой сохранения блоков совместимости по крайней мере для двух основных версий. Прочтите следующий раздел для примера.
Политика устаревания ¶
Основная версия может сделать некоторые функции предыдущих версий устаревшими. Если функция устарела во время основного выпуска A.x
, она продолжит работать во всех выпусках A.x
(независимо от x), но будет выдавать предупреждения. Устаревшие функции будут удалены в версии B.0 или B.1 для функций, ставших устаревшими в последней версии Axe, чтобы предупреждения об устаревании появлялись как минимум в двух основных версиях.
Например, если мы решили отказаться от функции в Django 4.2:
- Django 4.2 будет содержать обратно совместимую копию функции, но с предупреждением
RemovedInDjango51Warning
. - Django 5.0 (версия после 4.2) по-прежнему будет содержать обратно совместимую копию.
- Django 5.1 полностью удалит эту функцию.
По умолчанию предупреждения не отображаются. Вы можете отобразить эти предупреждения с помощью параметра -Wd
Python.
Более общий пример
- X.0
- Х.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 поддержит набор релизов разного уровня. См. Раздел поддерживаемых версий на странице загрузки, чтобы узнать о текущем состоянии поддержки для каждой версии.
Основная ветвь разработки получает новые функции и исправления ошибок, требующие нетривиального анализа кода.
Патчи, применяемые к основной ветке, также должны быть применены к последней стабильной ветке выпуска, чтобы они были выпущены в следующем выпуске исправлений в этой серии, если они относятся к исправлениям критических проблем:
- Нарушения безопасности.
- Ошибки, вызывающие потерю данных.
- Ошибки, вызывающие сбои.
- Основные функциональные ошибки в новых функциях в последней стабильной версии.
- Отклонения от старых версий Django, представленных в текущей серии выпусков.
Практическое правило заключается в том, что исправления переносятся в последнюю стабильную версию, если это ошибки, которые заблокировали бы нормальный выпуск (блокировщики сообщений).
Исправления безопасности и ошибки потери данных применяются к текущей основной ветке, двум последним ветвям стабильного выпуска и любой другой ветке, которая является частью долгосрочной поддержки (LTS).
Исправления документации обычно более свободно переносятся в ветку последней версии. Это потому, что очень выгодно иметь актуальную и правильную документацию для последней версии, а риск введения регрессии вызывает гораздо меньше беспокойства.
В качестве конкретного примера рассмотрим момент на полпути между выпуском Django 5.1 и 5.2. На данный момент:
- Функции будут добавлены в мастер разработки, который будет выпущен как Django 5.2.
- Критические исправления ошибок будут применены к
stable/5.1.x
ветке и выпущены как 5.1.1, 5.1.2 и т. Д. - Ошибка безопасности фиксированная и фиксированный по вопросам потери данных будет применяться к
master
и к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 следует графику выпуска с фиксированной датой, при этом основные выпуски выпускаются примерно каждые 8 месяцев.
После каждого основного выпуска Release Manager объявляет график следующего основного выпуска.
Цикл выпуска ¶
Каждый цикл выпуска состоит из трех частей:
Этап 1: предложения функций ¶
Первый этап процесса выпуска включает оценку основных функций, которые будут включены в следующий выпуск. Это означает, что большая часть предварительной работы над этими функциями уже проделана, а функциональный код всегда предпочтительнее больших идей.
Основные особенности предстоящего поста будут добавлены на вики-страницу дорожной карты, например. https://code.djangoproject.com/wiki/Version1.11Roadmap .
Фаза 2: разработка ¶
Вторая часть графика релизов - это период работы "без головы". Используя дорожную карту, подготовленную в конце первого этапа, мы все будем очень много работать, чтобы все на ней сделать.
В конце второй фазы все незавершенные функции будут отложены до следующего выпуска.
Вторая фаза завершится выпуском альфа-версии. На этом этапе
stable/A.B.x
ветвь будет разветвлена master
.
Этап третий: исправления ¶
Последняя часть цикла выпуска посвящена исправлению ошибок - новые функции в это время не принимаются. Мы постараемся выпустить бета-версию через месяц после альфа и релиз-кандидата через месяц после нее.
Релиз-кандидат отмечает замораживание строк, и это происходит как минимум за две недели до финального релиза. После этого нельзя добавлять новые переводимые строки.
На этом этапе коммиттеры будут все более и более консервативными в отношении бэкпортов, чтобы избежать регрессии. После релиз-кандидата следует переносить только блокировщики релизов и исправления документации.
Параллельно с этим этапом master
могут появиться новые функции, которые будут выпущены в A.B+1
цикле.
Релизы с исправлениями ошибок ¶
После основного выпуска (например, AB) предыдущая версия переходит в режим исправления ошибок.
Ветвь для предыдущего выпуска функций (например stable/A.B-1.x
) будет включать исправления. Критические ошибки, исправленные на мастере, также должны быть исправлены в ветке исправления ошибок ; это означает, что коммитам необходимо четко отделить исправления ошибок от дополнений функций. Разработчик, передающий исправление в master, также будет нести ответственность за применение исправления к текущей ветке исправления.