Djangos källkodsarkiv

När du distribuerar en Django-applikation till en riktig produktionsmiljö vill du nästan alltid använda ”en officiell paketerad version av Django”.

Men om du vill prova kod under utveckling från en kommande version eller bidra till utvecklingen av Django, måste du skaffa en klon av Djangos källkodsarkiv.

Det här dokumentet beskriver hur kodarkivet är uppbyggt och hur man arbetar med och hittar saker i det.

Översikt på hög nivå

Djangos källkodsarkiv använder Git för att spåra ändringar i koden över tid, så du behöver en kopia av Git-klienten (ett program som heter git) på din dator, och du vill bekanta dig med grunderna i hur Git fungerar.

Gits webbplats erbjuder nedladdningar för olika operativsystem. Webbplatsen innehåller också stora mängder dokumentation.

Djangos Git-förvar finns online på github.com/django/django. Den innehåller den fullständiga källkoden för alla Django-versioner, som du kan bläddra i online.

Git-förvaret innehåller flera ”grenar”:

• main innehåller den huvudsakliga koden under utveckling som kommer att bli nästa paketerade version av Django. Det är här den mesta utvecklingsaktiviteten är fokuserad.

• stable/A.B.x är de grenar där arbetet med att förbereda releaser sker. De används också för buggfix- och säkerhetsreleaser som sker vid behov efter den första releasen av en funktionsversion.

Git-förvaret innehåller också tags. Dessa är de exakta revisionerna från vilka paketerade Django-versioner producerades, sedan version 1.0.

Ett antal taggar finns också under prefixet archive/ för :ref:``archived work<archived-feature-development-work>`.

Källkoden för webbplatsen Djangoproject.com finns på github.com/django/djangoproject.com.

Huvudgrenen

Om du vill prova den kod som är under utveckling för nästa version av Django, eller om du vill bidra till Django genom att åtgärda buggar eller utveckla nya funktioner, bör du hämta koden från huvudgrenen.

Observera

Före mars 2021 kallades huvudgrenen för master.

Observera att detta kommer att få allt av Django: förutom toppnivån django-modulen som innehåller Python-kod, får du också en kopia av Djangos dokumentation, testsvit, förpackningsskript och andra diverse bitar. Djangos kod kommer att finnas i din klon som en katalog med namnet django.

För att prova den kod som är under utveckling med dina egna applikationer, placera katalogen som innehåller din klon på din Python-importväg. Då kommer import-uttalanden som letar efter Django att hitta django-modulen i din klon.

Om du kommer att arbeta med Djangos kod (till exempel för att fixa en bugg eller utveckla en ny funktion) kan du förmodligen sluta läsa här och gå vidare till dokumentationen för att bidra till Django, som täcker saker som den föredragna kodningsstilen och hur man genererar och skickar in en patch.

Stabila grenar

Django använder grenar för att förbereda sig inför releaser av Django. Varje större release-serie har sin egen stabila gren.

Dessa grenar finns i arkivet som stable/A.B.x grenar och kommer att skapas direkt efter att den första alfan är taggad.

Till exempel, omedelbart efter att Django 1.5 alpha 1 taggades, skapades grenen stable/1.5.x och allt ytterligare arbete med att förbereda koden för den slutliga 1.5-utgåvan gjordes där.

Dessa grenar ger också stöd för buggfixar och säkerhet enligt beskrivningen i Versioner som stöds.

Till exempel, efter lanseringen av Django 1.5 får grenen stable/1.5.x endast korrigeringar för säkerhets- och kritiska stabilitetsbuggar, som så småningom släpps som Django 1.5.1 och så vidare, stable/1.4.x får endast säkerhets- och dataförlustkorrigeringar, och stable/1.3.x får inte längre några uppdateringar.

Historisk information

Denna policy för hantering av grenarna stable/A.B.x antogs från och med Django 1.5:s utgivningscykel.

Tidigare skapades dessa grenar inte förrän direkt efter utgåvorna och stabiliseringsarbetet skedde på huvudförvarets gren. Således kunde inget utvecklingsarbete för nya funktioner för nästa version av Django göras förrän den slutliga versionen hade släppts.

Till exempel, kort efter lanseringen av Django 1.3 skapades grenen stable/1.3.x. Det officiella stödet för den utgåvan har upphört, och därför får den inte längre direkt underhåll från Django-projektet. Den och alla andra grenar med liknande namn fortsätter dock att existera, och intresserade medlemmar har ibland använt dem för att ge inofficiellt stöd för gamla Django-versioner.

Taggar

Varje Django-release är märkt och signerad av releasegivaren.

Taggarna finns på GitHubs tags-sida.

Arkiverad funktion-utvecklingsarbete

Historisk information

Sedan Django flyttade till Git 2012 kan vem som helst klona arkivet och skapa sina egna grenar, vilket minskar behovet av officiella grenar i källkodsarkivet.

Följande avsnitt är mest användbart om du utforskar arkivets historia, till exempel om du försöker förstå hur vissa funktioner utformades.

Funktionsutvecklingsgrenar tenderar av sin natur att vara tillfälliga. Vissa producerar framgångsrika funktioner som slås samman tillbaka till Djangos huvudgren för att bli en del av en officiell utgåva, men andra gör det inte; i båda fallen kommer det en tid då grenen inte längre aktivt arbetas med av någon utvecklare. Vid denna tidpunkt anses grenen vara stängd.

Django brukade underhållas med revisionskontrollsystemet Subversion, som inte har något standardiserat sätt att ange detta. Som en lösning flyttades grenar av Django som är stängda och inte längre underhålls till attic.

Ett antal taggar finns under prefixet archive/ för att upprätthålla en referens till detta och andra verk av historiskt intresse.

Följande taggar under prefixet archive/attic/ refererar till toppen av grenar vars kod så småningom blev en del av Django själv:

• boulder-oracle-sprint: Lagt till stöd för Oracle-databaser i Djangos objekt-relationella mappare. Detta har varit en del av Django sedan 1.0-utgåvan.

• gis: Lagt till stöd för geografiska/spatiala frågor till Djangos objekt-relationella mappare. Detta har varit en del av Django sedan 1.0-utgåvan, som den medföljande applikationen django.contrib.gis.

• i18n: Lade till internationaliseringsstöd till Django. Detta har varit en del av Django sedan 0.90-utgåvan.

• magisk-removal: En större refaktorisering av både de interna och publika API:erna i Djangos objekt-relationella mappare. Detta har varit en del av Django sedan 0.95-utgåvan.

• multi-auth: En omarbetning av Djangos medföljande autentiseringsramverk som lade till stöd för autentiseringsbackends. Detta har varit en del av Django sedan 0.95-utgåvan.

• ny-admin: En refaktorisering av Djangos medföljande administrativa applikation. Detta blev en del av Django från och med 0.91-utgåvan, men ersattes av en annan refaktorisering (se nästa lista) före Django 1.0-utgåvan.

• newforms-admin: Den andra refaktoriseringen av Djangos medföljande administrativa applikation. Detta blev en del av Django från och med 1.0-utgåvan och är grunden för den nuvarande inkarnationen av django.contrib.admin.

• queryset-refactor: En refaktorisering av de interna delarna av Djangos objekt-relationella mappare. Detta blev en del av Django från och med 1.0-utgåvan.

• unicode: En refaktorisering av Djangos interna funktioner för att konsekvent använda Unicode-baserade strängar på de flesta ställen inom Django och Django-applikationer. Detta blev en del av Django från och med 1.0-utgåvan.

Dessutom hänvisar följande taggar under prefixet archive/attic/ till tipsen på grenar som stängdes, men vars kod aldrig slogs samman till Django, och de funktioner som de syftade till att implementera blev aldrig färdiga:

• full-historia

• generisk-auth

• stöd för flera databaser

• per-objekt-behörigheter

• schema-evolution

• schema-evolution-ng

• search-api

• `sqlalchemy

Slutligen, under prefixet archive/, innehåller arkivet soc20XX/<project> taggar som refererar till spetsen på grenar som användes av studenter som arbetade med Django under 2009 och 2010 års Google Summer of Code-program.