Djangos lanseringsprocess

Officiella utgivningar

Sedan version 1.0 fungerar Djangos versionsnumrering på följande sätt:

• Versionerna är numrerade i form av ”A.B” eller ”A.B.C”.

• A.B är versionsnumret för funktionsutgåvan. Varje version kommer att vara mestadels bakåtkompatibel med den föregående versionen. Undantag från denna regel kommer att listas i versionsnoterna.

• C är versionsnumret för patch release, som ökas för bugfix- och säkerhetsreleaser. Dessa utgåvor kommer att vara 100% bakåtkompatibla med den tidigare patchutgåvan. Det enda undantaget är när ett säkerhets- eller dataförlustproblem inte kan åtgärdas utan att bakåtkompatibiliteten bryts. Om detta inträffar kommer releaseanteckningarna att innehålla detaljerade uppgraderingsinstruktioner.

• Innan en ny funktion släpps gör vi alfa-, beta- och releasekandidatversioner. Dessa är av formen A.B alpha/beta/rc N, vilket betyder den N:e alpha/beta/release candidate av version A.B.

I git kommer varje Django-version att ha en tagg som anger dess versionsnummer, signerad med Django-versionens nyckel. Dessutom har varje versionsserie sin egen gren, kallad stable/A.B.x, och bugfix-/säkerhetsversioner kommer att utfärdas från dessa grenar.

För mer information om hur Django-projektet utfärdar nya versioner av säkerhetsskäl, se vår säkerhetspolicy.

Feature-utgåva

Funktionsreleaser (A.B, A.B+1, etc.) kommer att ske ungefär var åttonde månad - se release process för detaljer. Dessa utgåvor kommer att innehålla nya funktioner, förbättringar av befintliga funktioner och så vidare.

Patch release

Patchreleaser (A.B.C, A.B.C+1, etc.) kommer att utfärdas vid behov för att åtgärda buggar och/eller säkerhetsproblem.

Dessa utgåvor kommer att vara 100% compatibla med den tillhörande funktionsutgåvan, såvida inte detta är omöjligt av säkerhetsskäl eller för att förhindra dataförlust. Så svaret på frågan ”Ska jag uppgradera till den senaste patchversionen?” kommer alltid att vara ”ja”

Långsiktig stödutbetalning

Vissa funktionsutgåvor kommer att betecknas som LTS-utgåvor (Long Term Support). Dessa versioner kommer att få säkerhets- och dataförlustfixar tillämpade under en garanterad tidsperiod, vanligtvis tre år.

Se ”nedladdningssidan” för de utgåvor som har utsetts för långsiktig support.

Släppfrekvens

Från och med Django 2.0 kommer versionsnummer att använda en lös form av semantisk versionering så att varje version som följer en LTS kommer att gå till nästa ”dot zero”-version. Till exempel: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), etc.

SemVer gör det lättare att snabbt se hur kompatibla releaser är med varandra. Det hjälper också till att förutse när kompatibilitetsshims kommer att tas bort. Det är inte en ren form av SemVer eftersom varje funktionsutgåva kommer att fortsätta att ha några dokumenterade bakåtkompatibiliteter där en avskrivningsväg inte är möjlig eller inte är värd kostnaden. Dessutom kommer avskrivningar som påbörjats i en LTS-version (X.2) att tas bort i en icke-punkt-noll-version (Y.1) för att tillgodose vår policy att behålla avskrivningsskivor för minst två funktionsversioner. Läs vidare till nästa avsnitt för ett exempel.

Avskrivningspolicy

I en funktionsversion kan vissa funktioner från tidigare utgåvor utgå. Om en funktion är föråldrad i funktionsversion A.x kommer den att fortsätta att fungera i alla A.x-versioner (för alla versioner av x) men ge upphov till varningar. Föråldrade funktioner kommer att tas bort i B.0-versionen, eller B.1 för funktioner som föråldrades i den senaste A.x-funktionsversionen för att säkerställa att föråldringar görs över minst 2 funktionsversioner.

Så, till exempel, om vi bestämde oss för att börja avskriva en funktion i Django 4.2:

• Django 4.2 kommer att innehålla en bakåtkompatibel kopia av funktionen som kommer att ge upphov till en RemovedInDjango51Warning.

• Django 5.0 (den version som följer efter 4.2) kommer fortfarande att innehålla den bakåtkompatibla repliken.

• Django 5.1 kommer att ta bort funktionen helt och hållet.

Varningarna är tysta som standard. Du kan aktivera visning av dessa varningar med alternativet python -Wd.

Ett mer generiskt exempel:

• X.0

• X.1

• X.2 LTS

• Y.0: Drop deprecation shims läggs till i X.0 och X.1.

• Y.1: Drop deprecation shims tillagd i X.2.

• Y.2 LTS: Inga deprecation shims droppade (medan Y.0 inte längre stöds måste tredjepartsappar upprätthålla kompatibilitet tillbaka till X.2 LTS för att underlätta uppgraderingar från LTS till LTS).

• Z.0: Drop deprecation shims läggs till i Y.0 och Y.1.

Se även guiden Avveckling av en funktion.

Versioner som stöds

Vid varje tidpunkt kommer Djangos utvecklarteam att stödja en uppsättning utgåvor i varierande grad. Se ”avsnittet om versioner som stöds” <https://www.djangoproject.com/download/#supported-versions>`_ på nedladdningssidan för aktuellt stöd för varje version.

• Den nuvarande utvecklingsgrenen main kommer att få nya funktioner och buggfixar som kräver icke-trivial refaktorisering.

• Patchar som appliceras på huvudgrenen måste också appliceras på den sista feature release-grenen, för att släppas i nästa patch release av den feature-serien, när de åtgärdar kritiska problem:

  • Säkerhetsfrågor.

  • Fel vid dataförlust.

  • Kraschande buggar.

  • Större funktionsbuggar i nya funktioner i den senaste stabila versionen.

  • Regressioner från äldre versioner av Django som införts i den aktuella versionsserien.

  Tumregeln är att korrigeringar kommer att backporteras till den senaste funktionsreleasen för buggar som skulle ha förhindrat en release i första hand (release blockers).

• Säkerhetsfixar och buggar för dataförlust kommer att tillämpas på den aktuella huvudgrenen, de två senaste funktionsreleasegrenarna och alla andra releasegrenar för långsiktig support som stöds.

• Dokumentationsfixar kommer i allmänhet att backporteras mer fritt till den senaste release-grenen. Det beror på att det är mycket fördelaktigt att dokumentationen för den senaste utgåvan är uppdaterad och korrekt, och risken för att införa regressioner är mycket mindre.

Som ett konkret exempel kan man tänka sig en tidpunkt halvvägs mellan lanseringen av Django 5.1 och 5.2. Vid denna tidpunkt:

• Funktioner kommer att läggas till i huvudgrenen för utveckling, som kommer att släppas som Django 5.2.

• Kritiska buggfixar kommer att tillämpas på grenen stable/5.1.x och släppas som 5.1.1, 5.1.2, etc.

• Säkerhetsfixar och buggfixar för problem med dataförlust kommer att tillämpas på main och på grenarna stable/5.1.x, stable/5.0.x och stable/4.2.x (LTS). De kommer att utlösa utgivningen av 5.1.1, 5.0.5, 4.2.8, etc.

• Dokumentationsfixar kommer att tillämpas på main och, om det är lätt att backportera, på den senaste stabila grenen, 5.1.x.

Process för frisläppande

Django använder ett tidsbaserat utgivningsschema, med funktionsutgåvor var åttonde månad eller så.

Efter varje funktionsrelease publicerar release managern en tidslinje för nästa funktionsrelease. Tidslinjen för en kommande funktionsutgåva finns på motsvarande wiki-färdplanssida, t.ex. https://code.djangoproject.com/wiki/Version6.0Roadmap.

Schema och steg för lansering av funktioner

Aktiv utveckling / Frysning av pre-feature

Arbetet med funktionsversionen A.B påbörjas efter funktionsfrysningen av den föregående versionen, dvs. när grenen stable/A.B-1.x förgrenas.

Du kan hitta den aktuella grenen under aktiv utveckling i Django release process på Trac.

Frysning av funktioner / Alpha release

Alla större och mindre funktioner, inklusive avskrivningar och brytande ändringar, måste vara sammanslagna vid funktionsfrysningen. Alla funktioner som inte är klara vid denna tidpunkt kommer att skjutas upp till nästa funktionsrelease.

Vid den här tidpunkten kommer grenen stable/A.B.x att delas från main.

Icke release blockerande buggfix frysning / Beta release

Efter alpha kommer alla buggfixar som sammanfogats i main också att backporteras till stable/A.B.x. Refaktorer bakåtporteras enligt sammanslagningen. Sammanslagare kommer att vara mer och mer konservativa med bakåtporteringar för att undvika att införa regressioner.

Parallellt med denna fas kan main fortsätta att ta emot nya funktioner, som släpps i cykeln A.B+1.

Frysning av översättningssträng / Release candidate release

Om det fortfarande kommer in en jämn ström av blockeringar vid det planerade datumet för releasekandidaten, kommer en beta 2 att släppas för att uppmuntra till ytterligare tester och datumet för releasekandidaten kommer att skjutas fram ~1 månad.

Release candidate markerar string freeze, och det sker minst två veckor före den slutliga utgåvan. Översättare kan då skicka in uppdaterade översättningar för att inkluderas i den slutliga utgåvan. Efter denna punkt får nya översättningsbara strängar inte läggas till.

Efter release candidate är det endast release blockers och dokumentationskorrigeringar som backporteras.

Slutlig release

Helst ska den slutliga versionen levereras två veckor efter den sista releasekandidaten.

Om det fortfarande finns stora fel 2 veckor efter release candidate kommer ett beslut att fattas om hur man ska gå vidare (sannolikt kommer ytterligare en release candidate att utfärdas och det slutliga releasedatumet kommer att skjutas fram).

Versioner med buggfixar

Efter en funktionsversion (t.ex. A.B) kommer den tidigare versionen att övergå till buggfixläge.

Grenen för den föregående funktionsutgåvan (t.ex. stable/A.B-1.x) kommer att innehålla buggfixar. Kritiska fel som åtgärdas på huvudgrenen måste också åtgärdas på buggfixgrenen; detta innebär att överföringar måste separera buggfixar från funktionstillägg på ett tydligt sätt. Den utvecklare som överför en rättelse till huvudgrenen kommer att vara ansvarig för att även tillämpa rättelsen på den aktuella buggfixgrenen.