Процесс выпуска Django

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

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

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

  • A.B is the major version number. Each version will be mostly backwards compatible with the previous release. Exceptions to this rule will be listed in the release notes. When B == 9, the next major release will be A+1.0. For example, Django 2.0 will follow Django 1.9. There won’t be anything special about “dot zero” releases.
  • C is the minor version number, which is incremented for bug and security fixes. A new minor release will be 100% backwards-compatible with the previous minor release. The only exception is when a security or data loss issue can’t be fixed without breaking backwards-compatibility. If this happens, the release notes will provide detailed upgrade instructions.
  • Before a new major release, we’ll make alpha, beta, and release candidate releases. These are of the form A.B alpha/beta/rc N, which means the Nth alpha/beta/release candidate of version A.B.

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

Подробнее о том, как подготавливаются релизы безопасности можно прочитать в our security policies.

Major release

Major releases (1.5, 1.6, etc.) will happen roughly every nine months – see `release process`_, below for details. These releases will contain new features, improvements to existing features, and such.

A major release may deprecate certain features from previous releases. If a feature is deprecated in version A.B, it will continue to work in versions A.B and A.B+1 but raise warnings. It will be removed in version A.B+2.

So, for example, if we decided to start the deprecation of a function in Django 1.7:

  • Django 1.7 will contain a backwards-compatible replica of the function which will raise a RemovedInDjango19Warning. This warning is silent by default; you can turn on display of these warnings with the -Wd option of Python.
  • Django 1.8 will still contain the backwards-compatible replica. This warning becomes loud by default, and will likely be quite annoying.
  • Django 1.9 will remove the feature outright.
Minor release

Minor releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to fix security issues.

These releases will be 100% compatible with the associated major release, unless this is impossible for security reasons or to prevent data loss. So the answer to “should I upgrade to the latest minor release?” will always be “yes.”

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

В любой момент разработчики Django в той или иной степени поддерживают ряд релизов:

  • Все новые возможности, а также рефакторинг и исправление ошибок, будут внесены в текущую ветку разработки.

  • Patches applied to the master branch must also be applied to the last major release, to be released as the next minor release, when they fix critical problems:

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

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

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

    The rule of thumb is that fixes will be backported to the last major release for bugs that would have prevented a release in the first place (release blockers).

  • Security fixes and data loss bugs will be applied to the current master, the last two major releases, and the current LTS release.

  • Исправления документации очень часто переносятся в ветку последнего релиза. Происходит это потому что выгодно иметь свежую и правильную документацию последнего выпуска, а риск проявления регрессии ничтожно мал.

Рассмотрим конкретный пример, когда мы находимся на полпути от Django 1.6 к Django 1.7:

  • Новая функциональность добавляется в master-ветку разработки Django 1.7.

  • Исправление критических ошибок будет применено к ветке stable/1.6.x и выпущено под версиями 1.6.1, 1.6.2...

  • Security fixes and bug fixes for data loss issues will be applied to master and to the stable/1.6.x, stable/1.5.x, and stable/1.4.x (LTS) branches. They will trigger the release of 1.6.1, 1.5.1, 1.4.1, etc.
  • Documentation fixes will be applied to master, and, if easily backported, to the 1.6.x branch.

Long-term support (LTS) releases

Additionally, the Django team will occasionally designate certain releases to be “Long-term support” (LTS) releases. LTS releases will get security and data loss fixes applied for a guaranteed period of time, typically 3+ years, regardless of the pace of releases afterwards.

The follow releases have been designated for long-term support:

  • Django 1.4, supported until at least March 2015.

Процесс выпуска

Django uses a time-based release schedule, with major (i.e. 1.6, 1.7, etc.) releases every nine months, or more, depending on features.

После каждого релиза происходит несколько недель затишья, в течении которых разработчики ядра готовят план и дорожную карту для следующего релиза. Большинство изменений укладываются в 6-9 месяцев, но из-за некоторых больших работ эти сроки могут увеличиться.

Цикл релиза

Каждый цикл разделён на 3 периода, которые примерно равны по времени:

Фаза первая: предложение новой функциональности

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

В конце концов разработчики ядра предлагают такой список, который разделён на следующие категории:

  • “Must-have”: критическая функциональность, без которой релиз не выйдет

  • “Maybe”: работа по этим пунктам может быть перенесена на потом.

  • “Not going to happen”: работа по этим пунктам будет перенесена на потом.

Anything that hasn’t got at least some work done by the end of the first third isn’t eligible for the next release; a design alone isn’t sufficient.

Фаза вторая: разработка

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

Увеличение времени выхода как правило связано именно с этой фазой.

В конце второй фазы незавершённые “maybe” фичи будут перенесены в следующий релиз. Функциональность из списка “must-have” является обязательной, что может увеличить время выхода релиза.

Результатом разработки становится создание ветки stable/A.B.x, которая отделяется от master.

Фаза третья: исправление ошибок

Последняя треть цикла тратится на исправление ошибок – никакая новая функциональность более не принимается. Мы стараемся выпустить бета-версию через месяц, а RC спустя ещё один.

Выпуск RC замораживает строковые константы, это случается как минимум за 2 недели до выпуска релиза. После этого новые переводы строк не принимаются.

В течении этой фазы разработчики становятся всё более консервативными в применении патчей, чтобы избежать регрессии. После выпуска RC принимаются только исправления блокирующих ошибок и документации.

В это же время в ветке master может начать появляться новая функциональность, которая будет рассмотрена в цикле релиза A.B+1.

Релизы исправлений

After a major release (e.g. 1.6), the previous release will go into bugfix mode.

The branch for the previous major release (e.g. stable/1.5.x) will include bugfixes. Critical bugs fixed on master must also be fixed on the bugfix branch; this means that commits need to cleanly separate bug fixes from feature additions. The developer who commits a fix to master will be responsible for also applying the fix to the current bugfix branch.