O repositório de código-fonte do Django

Quando estiver fazendo deploy de uma aplicação Django em um ambiente de produção real, você quase sempre vai querer usar uma release do Django oficial.

Entretanto, se você quiser tentar o código em desenvolvimento de uma próxima release ou contribuir para o desenvolvimento do Django, você terá que obter um clone do repositório de código-fonte do Django.

Este documento cobre a maneira como o repositório de código é estruturado e como trabalhar e encontrar coisas dentro dele.

Visão de alto nível

O repositório de código-fonte do Django usa Git para rastrear mudanças no código durante o tempo, então você vai precisar de uma cópia do client do Git (um programa chamado git) no seu computador, e você quer familiarizar-se com o básico de como o Git trabalha.

O website do Git oferece download para vários sistemas operacionais. O site ainda contém vastas quantias de documentation.

O repositório do Django no GIt é localizado online em github.com/django/django. Ele contém todo o código-fonte para todas as releases do Django, que você pode navegar online.

O repositório Git inclui várias branches:

  • master contém o principal código em desenvolvimento e que se tornará a próxima versão de release do Django. Esse é o lugar onde a maior parte do atividade de desenvolvimento é realizada.
  • stable/A.B.x são branches onde o trabalho de preparação de release acontece. Elas também são usadas para correção de bugs e releases de segurança que ocorrem a depender da necessidade depois que a versão final.
  • As branches soc20XX/<project> são usadas por estudantes que trabalham no Django durante os programas Google Summer of Code de 2009 e 2010.
  • As branches attic/<project> são usadas para desenvolver funcionalidades maiores ou experimentais sem afetar o restando do código Django.

O repositório Git que contém as tags. Essas são as revisões exatas das quais as releases do Django foram produzidas, desde a versão 1.0.

O código-fonte para o website Djangoproject.com pode ser encontrado em github.com/django/djangoproject.com.

A branch master

Se você gostaria de testar o código em desenvolvimento da próxima versão do Django, ou se você gostaria de contribuir para o Django corrigindo bugs ou desenvolvendo novas funcionalidades, você vai querer pegar o código da master branch.

Note que isso irá pegar tudo do Django: além do módulo django contendo código Python, você irá também pegar uma cópia da documentação do Django, suíte de testes, scripts e outras coisas gerais. O código Django irá ser apresentado em seu clone como um diretório chamado django.

Para testar o código de desenvolvimento com suas próprias aplicações, simplesmente coloque o diretório contendo o seu clone no seu Python import path. Então os comandos import que procuram pelo Django irão encontrar o módulo django dentro do seu clone.

Se você estará trabalhando no código do Django (por exemplo, para corrigir bugs ou desenvolver uma nova funcionalidade), você pode provavelmente para de ler aqui e ir para a documentação para contribuições no Django, que cobre coisas como o estilo preferido de código e como gerar e submeter um patch.

Outras branches

O Django utiliza branches para preparar as releases do Django.

No passado quando o Django era hospedado no Subversion, branches também eram usadas para o desenvolvimento de funcionalidades. Agora o Django é hospedado no Git e o desenvolvimento de novas funcionalidades é realizado em forks de voluntários, mas as branches de funcionalidade do Subversion continuam no GIt para referência histórica.

Branches estáveis

Essas branches podem ser encontradas dentro das branches stable/A.B.x e serão criadas após realização de tag da primeira versão alpha.

Por exemplo, imediatamente após o tag da versão Django 1.5 alpha 1, a branch stable/1.5.x foi criada e todo o trabalho seguinte na preparação do código para a release final 1.5 foi feita nela.

These branches also provide bugfix and security support as described in Versões suportadas.

For example, after the release of Django 1.5, the branch stable/1.5.x receives only fixes for security and critical stability bugs, which are eventually released as Django 1.5.1 and so on, stable/1.4.x receives only security and data loss fixes, and stable/1.3.x no longer receives any updates.

Informação Histórica

Esta política para manipular branches stable/A.B.x foi adotada começando com o ciclo de release da versão Django 1.5.

Previously, these branches weren’t created until right after the releases and the stabilization work occurred on the main repository branch. Thus, no new feature development work for the next release of Django could be committed until the final release happened.

For example, shortly after the release of Django 1.3 the branch stable/1.3.x was created. Official support for that release has expired, and so it no longer receives direct maintenance from the Django project. However, that and all other similarly named branches continue to exist, and interested community members have occasionally used them to provide unofficial support for old Django releases.

Brances para o desenvolvimento de novas funcionalidades

Informação Histórica

Desde que o Django mudou para o Git em 2012, todos podem clocar o repositório e criar suas próprias branches. aliviando a necessidade de branches oficiais no repositório de código-fonte.

A seção seguinte é mais útil se você estiver explorando o histórico do repositório, por exemplo se você está tentando entender como alguma funcionalidade foi desenvolvida.

Feature-development branches tend by their nature to be temporary. Some produce successful features which are merged back into Django’s master to become part of an official release, but others do not; in either case, there comes a time when the branch is no longer being actively worked on by any developer. At this point the branch is considered closed.

Infelizmente, O Django costumava ser mantido com o sistema de versionamento de código Subversion, que não tem uma forma padrão de indicar isso. Como paliativo, as branches do Django que são fechadas e que não são mais mantidas são movidas dentro de attic.

Para referência, segue a seguir as branches das quais o código eventualmente se tornou parte do Django em si, e não são mais mantidas separadamente:

  • boulder-oracle-sprint: Adicionou suporte para os bancos de dados Oracle no ORM do Django. Ela tem sido parte do Django desde a release 1.0.
  • gis: Adiciona suporte para consultas geográficas/espaciais no ORM do Django. Ela tem sido parte do Django desde a release 1.0, foi embutida na aplicação django.contrib.gis.
  • i18n: Adiciona suporte a internacionalização ao Django. Ela tem sido parte do Django desde a relase 0.90.
  • magic-removal: Uma refatoração massiva tanto da API privada quanto da API pública do ORM do Django. Ela tem sido parte do Django desde a release 0.95.
  • multi-auth: Uma refatoração do framework de autenticação embutido no Django que adicionou suporte para backends de autenticação. Ela tem sido parte do Django desde a release 0.95.
  • new-admin: Uma refatoração da aplicação administrativa embutida no Django. Ela tem sido parte do Django desde a release 0.91, mas substituída foi por outra refatoração (veja a próxima listagem) antes da release do Django 1.0.
  • newforms-admin: A segunda refatoração da aplicação administrativa embutida no Django. Ela se tornou parte do Django na release 1.0, e é a base da encarnação atual do django.contrib.admin.
  • queryset-refactor: Uma refatoração das entranhas do ORM do Django. Ela se tornou parte do Django na release 1.0.
  • unicode: Uma refatoração das entranhas do Django para uso consistente de strings baseadas em Unicode e mais locais dentro do Django e de aplicações Django. Ela se tornou parte do Django na release 1.0.

When Django moved from Subversion to Git, the information about branch merges wasn’t preserved in the source code repository. This means that the master branch of Django doesn’t contain merge commits for the above branches.

Entretanto, a informação está disponível como um arquivo grafts. Você pode restaurá-lo colocando as linhas seguintes no arquivo .git/info/grafts` de seu clone local:

ac64e91a0cadc57f4bc5cd5d66955832320ca7a1 553a20075e6991e7a60baee51ea68c8adc520d9a 0cb8e31823b2e9f05c4ae868c19f5f38e78a5f2e
79e68c225b926302ebb29c808dda8afa49856f5c d0f57e7c7385a112cb9e19d314352fc5ed5b0747 aa239e3e5405933af6a29dac3cf587b59a099927
5cf8f684237ab5addaf3549b2347c3adf107c0a7 cb45fd0ae20597306cd1f877efc99d9bd7cbee98 e27211a0deae2f1d402537f0ebb64ad4ccf6a4da
f69cf70ed813a8cd7e1f963a14ae39103e8d5265 d5dbeaa9be359a4c794885c2e9f1b5a7e5e51fb8 d2fcbcf9d76d5bb8a661ee73dae976c74183098b
aab3a418ac9293bb4abd7670f65d930cb0426d58 4ea7a11659b8a0ab07b0d2e847975f7324664f10 adf4b9311d5d64a2bdd58da50271c121ea22e397
ff60c5f9de3e8690d1e86f3e9e3f7248a15397c8 7ef212af149540aa2da577a960d0d87029fd1514 45b4288bb66a3cda401b45901e85b645674c3988
9dda4abee1225db7a7b195b84c915fdd141a7260 4fe5c9b7ee09dc25921918a6dbb7605edb374bc9 3a7c14b583621272d4ef53061287b619ce3c290d
a19ed8aea395e8e07164ff7d85bd7dff2f24edca dc375fb0f3b7fbae740e8cfcd791b8bccb8a4e66 42ea7a5ce8aece67d16c6610a49560c1493d4653
9c52d56f6f8a9cdafb231adf9f4110473099c9b5 c91a30f00fd182faf8ca5c03cd7dbcf8b735b458 4a5c5c78f2ecd4ed8859cd5ac773ff3a01bccf96
953badbea5a04159adbfa970f5805c0232b6a401 4c958b15b250866b70ded7d82aa532f1e57f96ae 5664a678b29ab04cad425c15b2792f4519f43928
471596fc1afcb9c6258d317c619eaf5fd394e797 4e89105d64bb9e04c409139a41e9c7aac263df4c 3e9035a9625c8a8a5e88361133e87ce455c4fc13
9233d0426537615e06b78d28010d17d5a66adf44 6632739e94c6c38b4c5a86cf5c80c48ae50ac49f 18e151bc3f8a85f2766d64262902a9fcad44d937

Adicionalmente, as branches abaixo estão fechadas, mas os seus códigos nunca foram mesclados com o Django e as funcionalidades que elas buscavam implementar nunca foram concluídas:

  • full-history
  • generic-auth
  • multiple-db-support
  • per-object-permissions
  • schema-evolution
  • schema-evolution-ng
  • search-api
  • sqlalchemy

Todas as branches mencionadas acima agora residem em attic.

Finally, the repository contains soc2009/xxx and soc2010/xxx feature branches, used for the 2009 and 2010 Google Summer of Code projects.

Tags

Each Django release is tagged and signed by the releaser.

As tags podem ser encontradas na página do GitHub,

Back to Top