Desde a versão 1.0, As releases do Django são numeradas da seguinte forma:
\nVersõ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.
\nFeature 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.
\nPatch releases (A.B.C, A.B.C+1, etc.) serão emitidas quando necessário, para corrigir bugs e /ou problemas de segurança.
\nEssas 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”.
\nCertas 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.
\nVeja a página de download para saber quais são as releases que foram designadas como sendo long-term support.
\nComeçando com a versão 2.0 do Django, números de versões irão usar uma forma flexível de versionamento semântico de modo que cada versão seguinte a uma LTS irá colidir com a próxima versão “ponto zero”. Por exemplo: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), etc.
\nDescobrir 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.
\nUma 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.
\nEntão, por exemplo, se nós decidimos começar a depreciação de uma função no Django 4.2:
\nO Django 4.2 irá conter uma réplica da função compatível com versões anteriores que irá gerar um RemovedInDjango51Warning. Esse warning é silencioso por padrão; você pode habilitar a exibição desses warnings com a opção -Wd do Python.
Django 5.0 (a versão que segue a 4.2) ainda irá possuir a réplica da função compatível com versões anteriores. Esse warning se torna loud por padrão e irá provavelmente se tornar bem desagradável.
Django 5.1 irá remover a funcionalidade por completo.
Um exemplo mais genérico:
\nX.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.
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.
\nA master de desenvolvimento atual irá receber novas funcionalidades e correções de bug requerendo refatoração não trivial.
Patches aplicados na branch master também devem ser aplicados para a branch da última feature release, para que sejam lançados na próxima patch release da sére da feature, quando resolverem problemas críticos:
\nProblemas de segurança.
Bugs envolvendo perda de dados
Bugs que ocasionem em um crash da aplicação
Grandes bugs no funcionamento de funcionalidades recém introduzidas.
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).
\nCorreções de segurança e bugs que ocasionem perda de dados serão aplicados na master atual, nas branches das duas últimas feature releases e em quaisquer outras branches de releases com suporte de longa duração.
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:
\nFuncionalidades serão adicionadas na master de desenvolvimento, para que sejam lançadas no 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.
Correções de segurança e correções de bug envolvendo perda de dados serão aplicados nas branches master, stable/5.1.x, stable/5.0.x, e stable/4.2.x (LTS). Eles irão disparar as releases 5.1.1, 5.0.5, 4.2.8, etc.
Correções na documentação será aplicadas na master, e, se o backport for simples, para a última branch estável 5.1.x.
O Django usa um cronograma de release temporal com feature releases a cada oito meses ou algo próximo a isso.
\nDepois de cada feature release, o gerente de release irá anunciar uma linha do tempo para a próxima release.
\nCada ciclo de release consiste em três partes:
\nA 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.
\nGrandes funcionalidades para uma próxima release serão adicionadas a página wiki de roadmap, ex. https://code.djangoproject.com/wiki/Version1.9Roadmap.
\nA 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.
\nNo final da fase dois, qualquer funcionalidade não terminada será adiada até a próxima release.
\nA fase dois irá culminar com uma release alpha. Neste ponto, será feito um fork stable/A.B.x da branch master.
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.
\nA 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.
\nDurante essa fase, os committers serão mais e mais conservadores com os backports, para evitar a introdução de regressões. Depois do release candidate, só devem ser realizados backports de release blockers e de correções da documentação.
\nEm paralelo a essa fase, a master pode receber novas funcionalidades, para serem lançadas no ciclo A.B+1.
Depois da feature release (ex A.B), a release prévia irá entrar no modo de correção de bugs.
\nA branch para a feature release prévia (ex. stable/A.B-1.x) irá incluir correções de bugs. Bugs críticos corrigidos na master também devem ser corrigidas na branch de correção de bugs; isso significa que o commit precisa separar de modo limpo as correções de bugs das adições de funcionalidades. O desenvolvedor que fizer o commit de uma correção na master será responsável por também aplicar a correção para a branch de correção de bugs atual.