Процесс выпуска 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 на странице загрузки.

• The current development branch main will get new features and bug fixes requiring non-trivial refactoring.

• Patches applied to the main branch must also be applied to the last feature release branch, to be released in the next patch release of that feature series, when they fix critical problems:

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

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

• Security fixes and data loss bugs will be applied to the current main branch, the last two feature release branches, and any other supported long-term support release branches.

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

В качестве конкретного примера рассмотрим момент времени на полпути между выпуском Django 5.1 и 5.2. В этот момент времени:

• Features will be added to the development main branch, to be released as Django 5.2.
• Исправления критических ошибок будут применены к ветке stable/5.1.x и выпущены как 5.1.1, 5.1.2 и т.д.
• Security fixes and bug fixes for data loss issues will be applied to main and to the stable/5.1.x, stable/5.0.x, and stable/4.2.x (LTS) branches. They will trigger the release of 5.1.1, 5.0.5, 4.2.8, etc.
• Documentation fixes will be applied to main, and, if easily backported, to the latest stable branch, 5.1.x.

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

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

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