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.

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.

A number of tags also exist under the archive/ prefix for archived work.

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.

To try out the in-development code with your own applications, place the directory containing your clone on your Python import path. Then import statements which look for Django will find the django module within your 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.

Branches estáveis

Django uses branches to prepare for releases of Django. Each major release series has its own stable branch.

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.

Tags

Each Django release is tagged and signed by the releaser.

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

Archived feature-development work

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.

Django used to be maintained with the Subversion revision control system, that has no standard way of indicating this. As a workaround, branches of Django which are closed and no longer maintained were moved into attic.

A number of tags exist under the archive/ prefix to maintain a reference to this and other work of historical interest.

The following tags under the archive/attic/ prefix reference the tip of branches whose code eventually became part of Django itself:

• 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.

Additionally, the following tags under the archive/attic/ prefix reference the tips of branches that were closed, but whose code was never merged into Django, and the features they aimed to implement were never finished:

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

Finally, under the archive/ prefix, the repository contains soc20XX/<project> tags referencing the tip of branches that were used by students who worked on Django during the 2009 and 2010 Google Summer of Code programs.