Django är engagerat i API-stabilitet och framåtkompatibilitet. I ett nötskal betyder detta att kod som du utvecklar mot en version av Django kommer att fortsätta att fungera med framtida utgåvor. Du kan behöva göra mindre ändringar när du uppgraderar den version av Django som ditt projekt använder: se avsnittet ”Bakåtkompatibla ändringar” i release note för den version eller de versioner som du uppgraderar till.
\nSamtidigt som API-stabilitet är en mycket hög prioritet, är Django också engagerat i ständiga förbättringar, tillsammans med målet att ”ett sätt att göra det” (så småningom) i de API: er vi tillhandahåller. Detta innebär att när vi upptäcker klart överlägsna sätt att göra saker, kommer vi att avskriva och så småningom ta bort de gamla sätten. Vårt mål är att tillhandahålla ett modernt, pålitligt webbramverk av högsta kvalitet som uppmuntrar till bästa praxis i alla projekt som använder det. Genom att använda stegvisa förbättringar försöker vi undvika både stagnation och stora omvälvande uppgraderingar.
\nI detta sammanhang betyder stabil:
\nAlla offentliga API:er (allt i den här dokumentationen) kommer inte att flyttas eller byta namn utan att tillhandahålla bakåtkompatibla alias.
Om nya funktioner läggs till i dessa API:er - vilket är fullt möjligt - kommer de inte att bryta eller ändra betydelsen av befintliga metoder. Med andra ord betyder ”stabil” inte (nödvändigtvis) ”komplett”
Om ett API som förklarats stabilt av någon anledning måste tas bort eller ersättas, kommer det att förklaras som föråldrat men kommer att finnas kvar i API:et i minst två funktionsversioner. Varningar kommer att utfärdas när den föråldrade metoden anropas.
\nSe Officiella utgivningar för mer information om hur Djangos versionsnumreringssystem fungerar och hur funktioner kommer att avskrivas.
\nVi kommer endast att bryta bakåtkompatibiliteten för dessa API:er utan en utfasningsprocess om en bugg eller ett säkerhetshål gör det helt oundvikligt.
I allmänhet anses allt som omfattas av dokumentationen - med undantag för allt som finns i internals-området - vara stabilt.
\nDet finns några få undantag från detta löfte om stabilitet och bakåtkompatibilitet.
\nOm vi blir medvetna om ett säkerhetsproblem - förhoppningsvis genom att någon följer vår säkerhetsrapporteringspolicy - kommer vi att göra allt som krävs för att åtgärda det. Detta kan innebära att vi bryter bakåtkompatibiliteten; säkerhet trumfar kompatibilitetsgarantin.
\nVissa API:er är uttryckligen markerade som ”interna” på ett par olika sätt:
\nI viss dokumentation hänvisas till interndelar och de omnämns som sådana. Om det i dokumentationen står att något är internt förbehåller vi oss rätten att ändra det.
Funktioner, metoder och andra objekt som inleds med ett inledande understreck (_). Detta är Pythons standardmetod för att ange att något är privat; om en metod börjar med en enda _ är det ett internt API.