Процесс публикации 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, также будет нести ответственность за применение исправления к текущей ветке исправления.

Copyright ©2020 All rights reserved