Processo de release do Django¶

Releases oficiais¶

Desde a versão 1.0, As releases do Django são numeradas da seguinte forma:

Versões são numeradas na forma A.B ou A.B.C.
A.B é o número de versão da feature release. Cada versão será em grande parte compatível com as releases anteriores . Exceções a essa regra são listadas nas notas da release.
C é o número de versão da patch release, que é incrementada por correções de bug e releases de segurança. Essas releases serão 100% compatíveis com a patch release anterior. A única exceção é quando problemas de segurança ou de perda de dados não podem ser corrigidos sem quebrar a compatibilidade com versões anteriores. Se isso acontecer, as notas da release irão fornecer instruções detalhadas de upgrade.
Antes de uma nova feature release, nós vamos fazer releases alpha, beta e release candidate das versões A.B.

No git, cada release do Django irá ter uma tag indicando o seu número de versão , assinada com a chave de releases do Django. Adicionalmente, cada śerie de releases tem a su própria branch, chamada de stable/A.B.x, e releases de segurança ou correção de bugs serão geradas dessas branches.

Para mais informações sobre como o projeto Django emite novas releases para propósitos de segurança, por favor veja nossa política de segurança.

Feature release¶

Feature releases (A.B, A.B+1, etc.) irão ocorrer mais ou menos a cada oito meses – veja processo de release para detalhes. Essas releases irão conter novas funcionalidades, melhorias para funcionalidades existentes, e similares.

Patch release¶

Patch releases (A.B.C, A.B.C+1, etc.) serão emitidas quando necessário, para corrigir bugs e /ou problemas de segurança.

Essas releases serão 100% compatíveis com a feature release associada, a não ser que isso seja impossível por questões de segurança ou para prevenir perda de dados. Então a resposta para “será que devo atualizar para a última patch release?” sempre será “sim”.

Suporte de longo prazo a uma release¶

Certas feature releases serão designadas como sendo de long-term support (LTS). Essas releases irão receber correções de segurança e para perda de dados aplicadas por um período de tempo garantido, tipicamente três anos.

Veja a página de download para saber quais são as releases que foram designadas como sendo long-term support.

Cadência de uma release¶

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.

Descobrir como as releases são compatíveis entre si fica mais simples com SemVer. Ele também ajuda a antecipar quando calços de compatibilidade serão removidos. Ele não é uma forma pura do SemVer já que cada feature release irá continuar a ter algumas incompatibilidades com versões anteriores documentadas onde o caminho de depreciação não for possível ou onde ele não valha a pena. Além disso, as depreciações que começaram em uma release LTS (X.2) serão descartadas em uma release sem ponto zero (Y.1) para acomodar as nossas políticas de manter os calços de compatibilidade por pelo menos duas feature releases. Leia a próxima seção para um exemplo.

Política de depreciação¶

Uma feature release pode depreciar algumas funcionalidades de releases prévias. Se uma funcionalidade é depreciada em uma feature release A.x, ela irá continuar a funcionar em todas as versões A.x (para todas as versões de x) mas gerando warnings. Funcionalidades depreciadas serão removidas em uma release B.0, ou B.1 para features depreciadas na última feature release A.x para garantir que as depreciações sejam realizadas após pelo menos 2 feature releases.

Então, por exemplo, se nós decidimos começar a depreciação de uma função no Django 4.2:

Django 4.2 irá conter uma cópia compatível com versões anteriores da função que irá lançar um RemovedInDjango51Warning.
Django 5.0 (a versão imediatamente posterior a 4.2) ainda conterá a cópia compatível com versões anteriores.
Django 5.1 irá remover a funcionalidade por completo.

Os warnings são silenciosos por padrão. Você pode ativar a exibição desses warnings com a opção python -Wd.

Um exemplo mais genérico:

X.0
X.1
X.2 LTS
Y.0: Remove os calços de depreciação adicionados em X.0 e X.1.
Y.1: Remove os calços de depreciação adicionados em X.2.
Y.2 LTS: Nenhum calço de depreciação será retirado (embora Y.0 não seja mais suportada, apps de terceiros precisam manter compatibilidade com a versão anterior X.2 LTS para facilitar atualizações de LTS para LTS).
Z.0: Remove os calços de compatibilidade adicionados em Y.0 e Y.1.

See also the Depreciando uma funcionalidade guide.

Versões suportadas¶

A qualquer momento, o time de desenvolvedores do Django irão dar suporte a um conjunto de releases de vários leveis. Veja a seção de versões suportadas da página de downloads page para o estado atual de suporte de cada versão.

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:
- Problemas de segurança.
- Bugs de perda de dados
- Bugs que ocasionem em um crash da aplicação
- Major functionality bugs in new features of the latest stable release.
- Regressions from older versions of Django introduced in the current release series.
A regra prática é que serão feitos backports das correções para a última feature release para bugs que impediriam a conclusão da release em primeiro lugar (release blockers).
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.
Backports de correções de documentação geralmente serão mais livremente enviados para a branch da última release. Isso porque é altamente vantajoso possuir a última versão da documentação da última release atualizada e correta, e o risco de introduzir regressões é muito menor.

Como exemplo concreto, considere um momento no tempo entre a release do Django 5.1 e 5.2. Nesse momento no tempo:

Features will be added to the development main branch, to be released as Django 5.2.
Bugs críticos serão corrigidos e aplicados na branch stable/5.1.x, e lançados como 5.1.1, 5.1.2, etc.
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.

Processos da release¶

O Django usa um cronograma de release temporal com feature releases a cada oito meses ou algo próximo a isso.

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.

Feature release schedule and stages¶

Active development / Pre-feature freeze¶

Work begins on the feature release A.B after the feature freeze of the previous release, i.e. when the stable/A.B-1.x branch is forked.

You can find the current branch under active development in the Django release process on Trac.

Feature freeze / Alpha release¶

All major and minor features, including deprecations and breaking changes, must be merged by the feature freeze. Any features not done by this point will be deferred to the next feature release.

At this point, the stable/A.B.x branch will be forked from main.

Non-release blocking bug fix freeze / Beta release¶

After the alpha, all bug fixes merged in main are also backported to stable/A.B.x. Refactors are backported at the discretion of the merger. Mergers will be more and more conservative with backports, to avoid introducing regressions.

In parallel to this phase, main can continue to receive new features, to be released in the A.B+1 cycle.

Translation string freeze / Release candidate release¶

If there is still a consistent stream of release blockers coming in at the planned release candidate date, a beta 2 will be released to encourage further testing and the release candidate date will be pushed out ~1 month.

The release candidate marks the string freeze, and it happens at least two weeks before the final release. Translators can then submit updated translations for inclusion in the final release. After this point, new translatable strings must not be added.

After the release candidate, only release blockers and documentation fixes are backported.

Final release¶

Ideally, the final release will ship two weeks after the last release candidate.

If there are major bugs still being found 2 weeks after the release candidate, there will be a decision on how to proceed (likely another release candidate would be issued and the final release date will be pushed out).

Releases de correções de bugs¶

Depois da feature release (ex A.B), a release prévia irá entrar no modo de correção de bugs.

The branch for the previous feature release (e.g. stable/A.B-1.x) will include bugfixes. Critical bugs fixed on main 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 main will be responsible for also applying the fix to the current bugfix branch.