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.
For more information about how the Django project issues new releases for\nsecurity purposes, please see our security policies.
\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.
\nStarting with Django 2.0, version numbers will use a loose form of semantic\nversioning such that each version following an LTS will\nbump to the next “dot zero” version. For example: 2.0, 2.1, 2.2 (LTS), 3.0,\n3.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:
\nDjango 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:
\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.
See also the Depreciando uma funcionalidade guide.
\nA 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.
\nThe current development branch main will get new features and bug fixes\nrequiring non-trivial refactoring.
Patches applied to the main branch must also be applied to the last feature\nrelease branch, to be released in the next patch release of that feature\nseries, when they fix critical problems:
\nProblemas 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\nseries.
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).
\nSecurity fixes and data loss bugs will be applied to the current main branch,\nthe last two feature release branches, and any other supported long-term\nsupport 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:
\nFeatures will be added to the development main branch, to be released as\nDjango 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\nmain and to the stable/5.1.x, stable/5.0.x, and\nstable/4.2.x (LTS) branches. They will trigger the release of 5.1.1,\n5.0.5, 4.2.8, etc.
Documentation fixes will be applied to main, and, if easily backported, to\nthe latest stable branch, 5.1.x.
O Django usa um cronograma de release temporal com feature releases a cada oito meses ou algo próximo a isso.
\nAfter each feature release, the release manager will publish a timeline for the\nnext feature release. The timeline for an upcoming feature release can be found\nin the corresponding wiki roadmap page, e.g.\nhttps://code.djangoproject.com/wiki/Version6.0Roadmap.
\nWork begins on the feature release A.B after the feature freeze of the\nprevious release, i.e. when the stable/A.B-1.x branch is forked.
You can find the current branch under active development in the\nDjango release process on Trac.
\nAll major and minor features, including deprecations and breaking changes, must\nbe merged by the feature freeze. Any features not done by this point will be\ndeferred to the next feature release.
\nAt this point, the stable/A.B.x branch will be forked from main.
After the alpha, all bug fixes merged in main are also backported to\nstable/A.B.x. Refactors are backported at the discretion of the merger.\nMergers will be more and more conservative with backports, to avoid introducing\nregressions.
In parallel to this phase, main can continue to receive new features, to be\nreleased in the A.B+1 cycle.
If there is still a consistent stream of release blockers coming in at the\nplanned release candidate date, a beta 2 will be released to encourage further\ntesting and the release candidate date will be pushed out ~1 month.
\nThe release candidate marks the string freeze, and it happens at least two\nweeks before the final release. Translators can then submit updated\ntranslations for inclusion in the final release. After this point, new\ntranslatable strings must not be added.
\nAfter the release candidate, only release blockers and documentation fixes are\nbackported.
\nIdeally, the final release will ship two weeks after the last release\ncandidate.
\nIf there are major bugs still being found 2 weeks after the release candidate,\nthere will be a decision on how to proceed (likely another release candidate\nwould be issued and the final release date will be pushed out).
\nDepois da feature release (ex A.B), a release prévia irá entrar no modo de correção de bugs.
\nThe branch for the previous feature release (e.g. stable/A.B-1.x) will\ninclude bugfixes. Critical bugs fixed on main must also be fixed on the\nbugfix branch; this means that commits need to cleanly separate bug fixes from\nfeature additions. The developer who commits a fix to main will be\nresponsible for also applying the fix to the current bugfix branch.