O release do Django 1.0 vem com a promessa de estabilidade de API e compatibilidade futura. Em resumo, isto significa que o código que você construir utilizando o Django 1.0 irá funcionar com 1.1 sem mudanças, e você precisará fazer somente pequenas mudanças para qualquer release 1.x.
Neste contexto, “stable” significa:
Todas as APIs públicas – tudo que está documentado nos links abaixo, e todos os métodos que não comecem com um underscore – não serão movidas nem renomeadas sem fornecer aliases de compatibilidade anterior.
Se novas funcionalidades são adicionadas a essas APIs – o que é bem possível – elas não irão quebrar ou mudar o significado dos métodos existentes. Em outras palavras, “stable” não significa, necessariamente, “completo”.
Se, por alguma razão, uma API declarada “stable” tiver que ser removida ou substituída, ela será declarada obsoleta, porém irá permanecer até, pelo menos, duas novas versões secundárias. Avisos serão feitos quando um método obsoleto for chamado.
Veja Official releases para mais detalhes de como a numeração das versões do Django funciona, e como as funcionalidades entrarão em desuso.
Nós somente iremos quebrar a compatibilidade anterior dessas APIs se um bug ou uma falha de segurança fizer com que seja completamente inevitável.
Geralmente, tudo que foi documentado – com excessão de qualquer item da area interna é considerado “stable” na versão 1.0. Isto inclui estas APIs:
A maioria dos módulos em django.utils são projetados para uso interno. Somente as seguintes partes do django.utils podem ser consideradas estáveis:
Existem algumas poucas exceções para esta promessa de estabilidade e compatibilidade reversa.
Se nós tomarmos consciência de um problema de segurança – esperamos sigam a nossa política de relato de segurança – nós iremos fazer tudo o que for necessário para corrigí-lo. Isto pode significar quebra de compatibilidade; A segurança triunfa sobre a garantia de compatibilidade.
Nós faremos tudo para manter essas APIs estáveis – e não temos planos de quebrar qualquer aplicação do contrib – esta é uma área que terá mais fluxo entre os releases. Como a web evolui, o Django também deve evoluir com ela.
No entanto, eventuais alterações nas aplicações do contrib virão com uma importante garantia: faremos o necessário para que seja possível utilizar uma versão mais antiga de uma aplicação do contrib se precisarmos fazer alterações. Desta forma, se o Django 1.5 vem com uma incompatibilidade no django.contrib.flatpages, nós faremos de forma que você continue utilizando o Django 1.4 em paralelo com o Django 1.5. Isto continuará permitindo atualizações fáceis.
Historicamente, aplicações em django.contrib têm sido mais estáveis que o núcleo, então, na pratica, nós provavelmente nunca teremos que abrir essa exceção. Entretanto, é importante observar se você está construindo aplicações que dependam do django.contrib.
Algumas APIs são explicitamente marcadas como “internal” (interna, em inglês) de algumas maneiras:
Dec 26, 2011