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.

Depois de cada feature release, o gerente de release irá anunciar uma linha do tempo para a próxima release.

Ciclo da release

Cada ciclo de release consiste em três partes:

Fase um: propostas de funcionalidades

A primeira fase do processo de release inclui descobrir quais grandes funcionalidades incluir na próxima versão. Isso deve incluir uma boa quantidade de trabalho preliminar nessas funcionalidades – código que funciona é mais importante que um excelente design.

Major features for an upcoming release will be added to the wiki roadmap page, e.g. https://code.djangoproject.com/wiki/Version1.11Roadmap.

Fase dois: desenvolvimento

A segunda parte do cronograma da release é um período de “cabeça baixa”. Usando o roadmap produzido no final da fase um, nós vamos todos trabalhar duro para fazer com que tudo nele seja concluído.

No final da fase dois, qualquer funcionalidade não terminada será adiada até a próxima release.

Phase two will culminate with an alpha release. At this point, the stable/A.B.x branch will be forked from main.

Fase três: correções de bugs

A última parte do ciclo de release é gasto corrigindo bugs – novas funcionalidades não serão aceitas durante esse período. Nós vamos tentar soltar uma beta release um mês depois de uma alpha e uma release candidate um mês após a beta.

A release candidate marca o congelamento de strings, e ele ocorre pelo menos duas semanas antes da release final. Depois desse ponto, novas strings traduzíveis não devem ser adicionadas.

During this phase, mergers will be more and more conservative with backports, to avoid introducing regressions. After the release candidate, only release blockers and documentation fixes should be backported.

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

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.