Официальные релизы¶

Начиная с версии 1.0, версии Django нумеруются следующим образом:

• Номер версии выглядит как A.B или A.B.C.

• B - минорный номер версии, который увеличивается при большом объёме изменений, совместимых с предыдущими релизами. Код для Django 1.6 будет продолжать работать и под Django 1.7; исключения описаны в замечаниях к релизам.

• C - микро номер версии, который увеличивается по мере выпусков баг-фиксов. Он на 100% совместим с предыдущим выпуском, за исключением тех случаев, когда исправление безопасности невозможно без ёё нарушения. В любом случае это указано в замечании к релизу, в котором также приводятся рекомендации для обновления.

• Перед выпуском минорного релиза мы готовим альфа, бета и RC версии. Они обозначаются как A.B alpha/beta/rc N, где Nth - alpha/beta/rc версия A.B.

В git каждый релиз Django имеет свой тег, определяющий его номер, подписанный ключом. Также в репозитории каждый релиз находится в отдельной ветке под названием stable/A.B.x, а багфиксы выпускаются на основании уже этой ветки.

Дополнительную информацию о том, как проект Django выпускает новые выпуски в целях безопасности, см. в нашей политике безопасности.

Официальные релизы¶

Минорные релизы (1.5, 1.6…) выходят каждые 9 месяцев согласно release process. В них добавляются новые возможности, всяческие улучшения и пр.

Официальные релизы¶

Минорные релизы (1.5.1, 1.6.2, 1.6.1…) будут выпускаться по мере надобности, зачастую исправляя ошибки в безопасности.

Эти релизы на 100% совместимы с минорными версиями, если это не противоречит вопросам безопасности. Так что вы всегда можете обновляться без сомнений.

Long-term support release¶

Certain feature releases will be designated as long-term support (LTS) releases. These releases will get security and data loss fixes applied for a guaranteed period of time, typically three years.

See the download page for the releases that have been designated for long-term support.

Цикл релиза¶

Starting with Django 2.0, version numbers will use a loose form of semantic versioning such that each version following an LTS will bump to the next «dot zero» version. For example: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), etc.

SemVer makes it easier to see at a glance how compatible releases are with each other. It also helps to anticipate when compatibility shims будет удален. It’s not a pure form of SemVer as each feature release will continue to have a few documented backwards incompatibilities where a deprecation path isn’t possible or not worth the cost. Also, deprecations started in an LTS release (X.2) will be dropped in a non-dot-zero release (Y.1) to accommodate our policy of keeping deprecation shims for at least two feature releases. Read on to the next section for an example.

Deprecation policy¶

В минорных релизах некоторые функции могут быть объявлены устаревшими. Если какая-то функциональность объявлена устаревшей в A.B, она будет работать в A.B, в A.B+1 вызывать исключение, а в A.B+2 уже удалена.

Так, например, если мы объявили функциональность устаревшей в Django 1.5:

• В Django 1.5 будет добавлена обратная совместимость, вызывающая PendingDeprecationWarning. Исключения этого типа по умолчанию не отображаются, но вы можете их включить, запустив Python с опцией -Wd.

• В Django 1.6 будет добавлена обратная совместимость, вызывающая полноправное исключение DeprecationWarning. Это предупреждение достаточно громкое, чтобы начать вас раздражать.

• В Django 1.7 функциональность будет удалена.

The warnings are silent by default. You can turn on display of these warnings with the python -Wd option.

A more generic example:

• X.0

• X.1

• X.2 LTS

• Y.0: Drop deprecation shims added in X.0 and X.1.

• Y.1: Drop deprecation shims added in X.2.

• Y.2 LTS: No deprecation shims dropped (while Y.0 is no longer supported, third-party apps need to maintain compatibility back to X.2 LTS to ease LTS to LTS upgrades).

• Z.0: Drop deprecation shims added in Y.0 and Y.1.

See also the Депрекация функции guide.

Поддерживаемые версии¶

At any moment in time, Django’s developer team will support a set of releases to varying levels. See the supported versions section of the download page for the current state of поддержка each version.

• 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:

  • Вопросы безопасности.

  • Ошибки, ведущие к потере данных.

  • Падения приложения.

  • Опасные ошибки в новой функциональности.

  • Regressions from older versions of Django introduced in the current release series.

  Согласно правилам, исправления будут портированы в последний минорный релиз, если ошибка является блокирующей дальнейшую разработку.

• 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 1.6 к Django 1.7:

• Features will be added to the development main branch, to be released as Django 5.2.

• Исправление критических ошибок будет применено к ветке stable/1.6.x и выпущено под версиями 1.6.1, 1.6.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 есть расписание выпуска минорных (1.6, 1.7…) релизов, согласно которому это происходит каждые 9 месяцев или больше в зависимости от новой функциональности.

After each feature release, the release manager will publish a timeline for the next feature release. The timeline for an upcoming feature release can be found in the corresponding wiki roadmap page, e.g. https://code.djangoproject.com/wiki/Version6.0Roadmap.