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

Релиз функции¶

Релизы функций (A.B, A.B+1 и т.д.) будут происходить примерно каждые восемь месяцев - подробности смотрите в release process. Эти релизы будут содержать новые возможности, улучшения существующих возможностей и т.п.

Выпуск патча¶

Обновления (A.B.C, A.B.C+1 и т.д.) будут выпускаться по мере необходимости для исправления ошибок и/или проблем безопасности.

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

Выпуск долгосрочной поддержки¶

Определенные выпуски функций будут обозначены как выпуски долгосрочной поддержки (LTS). В этих выпусках исправления, связанные с безопасностью и потерей данных, будут применяться в течение гарантированного периода времени, обычно трех лет.

Релизы, назначенные для долгосрочной поддержки, см. в разделе the download page.

Каденция выпуска¶

Начиная с Django 2.0, номера версий будут использовать свободную форму semantic versioning таким образом, что каждая версия, следующая за LTS, будет переходить к следующей версии «точка ноль». Например: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS) и т.д.

SemVer позволяет с первого взгляда понять, насколько релизы совместимы друг с другом. Это также помогает предвидеть, когда будут удалены фиксы совместимости. Это не чистая форма SemVer, так как каждый выпуск функций будет продолжать иметь несколько задокументированных обратных несовместимостей, где путь обесценивания невозможен или не стоит затрат. Также обесценивание, начатое в выпуске LTS (X.2), будет отменено в выпуске без точки-ноль (Y.1), чтобы соответствовать нашей политике сохранения обесценивания по крайней мере для двух выпусков функций. Читайте следующий раздел для примера.

Политика амортизации¶

В функциональном выпуске могут быть устаревшими некоторые функции из предыдущих выпусков. Если функция устарела в выпуске функциональности A.x, она будет продолжать работать во всех версиях A.x (для всех версий x), но при этом будут выдаваться предупреждения. Устаревшие функции будут удалены в выпуске B.0 или B.1 для функций, устаревших в последнем выпуске A.x, чтобы гарантировать, что устаревание происходит как минимум в двух выпусках.

Так, например, если мы решили начать обесценивание функции в 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 будет поддерживать набор релизов на разном уровне. Текущее состояние поддержки каждой версии смотрите в the supported versions section на странице загрузки.

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

• Исправления, примененные к основной ветви, также должны быть применены к последней ветви выпуска функций, чтобы быть выпущенными в следующем выпуске патчей этой серии функций, если они устраняют критические проблемы:

  • Вопросы безопасности.
  • Ошибки при потере данных.
  • Ошибки при сбоях.
  • Основные функциональные ошибки в новых возможностях последнего стабильного релиза.
  • Отклонения от старых версий Django.

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

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

• Исправления документации, как правило, более свободно переносятся в ветку последнего релиза. Это потому, что очень выгодно, чтобы документация для последнего релиза была актуальной и правильной, и риск внесения регрессий гораздо меньше.

В качестве конкретного примера рассмотрим момент времени на полпути между выпуском 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 и т.д.
• Исправления документации будут применены к master, и, если они легко переносятся, к последней стабильной ветке, 5.1.x.

Процесс освобождения¶

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

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