{"title":"Så här släpper du Django","version":"5.2","locale":"sv","docname":"internals/howto-release-django","url":"/sv/5.2/internals/howto-release-django/","canonical":"https://djangodocs.dev/sv/5.2/internals/howto-release-django/","summary":"Detta dokument förklarar hur du släpper Django. Poängen här är att vara beskrivande, inte föreskrivande, så känn dig fri att effektivisera eller på annat sätt göra…","html":"

Så här släpper du DjangoLink to this heading#

\n

Detta dokument förklarar hur du släpper Django.

\n

Poängen här är att vara beskrivande, inte föreskrivande, så känn dig fri att effektivisera eller på annat sätt göra ändringar, men **uppdatera detta dokument i enlighet med detta!

\n
\n

ÖversiktLink to this heading#

\n

Det finns tre typer av releaser som du kan behöva göra:

\n\n

Den korta versionen av de inblandade stegen är:

\n
    \n

  1. Om det rör sig om en säkerhetsrelease ska du meddela säkerhetsdistributionslistan en vecka före den faktiska releasen.

    2. \n

  2. Korrekturläsa versionsinformation, leta efter organisations- och skrivfel. Skriva ett blogginlägg och ett e-postmeddelande.

    3. \n

  3. Uppdatera versionsnummer och skapa artefakter för releasen.

    4. \n

  4. Skapa den nya Release i administratören på djangoproject.com.

    \n
      \n

    1. Ange rätt datum men se till att flaggan is_active är inaktiverad.

      2. \n

    2. Ladda upp artefakterna (tarball, wheel och checksummor).

      3. \n
    \n
    5. \n

  5. Verifiera paketens signaturer, kontrollera om de kan installeras och säkerställa minimal funktionalitet.

    6. \n

  6. Ladda upp den nya versionen/versionerna till PyPI.

    7. \n

  7. Aktivera flaggan is_active för varje utgåva i administratören på djangoproject.com.

    8. \n

  8. Publicera blogginlägget och skicka ut e-postmeddelandena.

    9. \n

  9. Uppdatera versionsnummer efter release i stabila grenar.

    10. \n

  10. Lägg till stub versionsinformation för nästa patch release i main och backport.

    11. \n
\n

Det finns många detaljer, så läs gärna vidare.

\n
\n
\n

FörutsättningarLink to this heading#

\n

Du behöver några saker innan du sätter igång. Om det här är din första release måste du samordna med en annan releaser för att få allt detta klart, och skriva till Ops e-postlista och begära nödvändig åtkomst och behörigheter.

\n\n
\n
\n

Uppgifter före lanseringLink to this heading#

\n

Några saker måste tas om hand innan man ens påbörjar releaseprocessen. Det här börjar ungefär en vecka före lanseringen; det mesta kan göras när som helst fram till den faktiska lanseringen.

\n
\n

10 (eller fler) dagar före en säkerhetsreleaseLink to this heading#

\n
    \n

  1. Begär CVE IDs för säkerhetsfrågan (s) som släpps. Ett CVE-ID per fråga, begärd med Vendor: djangoproject och Product: django.

    2. \n

  2. Generera relevanta (privata) patchar med hjälp av git format-patch, en för main-grenen och en för varje stabil gren som patchar.

    3. \n
\n
\n
\n

En vecka före en säkerhetsreleaseLink to this heading#

\n
    \n

  1. Skicka ut ett förhandsmeddelande exakt en vecka före säkerhetsreleasen. Mallen för det e-postmeddelandet och en lista över mottagarna finns i den privata django-security GitHub-wikin. BCC mottagarna av föranmälan och se till att inkludera relevanta CVE-ID. Bifoga alla relevanta korrigeringar (riktade mot main och de stabila grenarna) och signera e-posttexten med den nyckel du kommer att använda för utgåvan, med ett kommando som:

    \n
    Shell
    $ gpg --clearsign --digest-algo SHA256 prenotification-email.txt\n
    \n
    2. \n

  2. Notify django-announce of the upcoming\nsecurity release with a general message such as:

    \n
    Text
    Notice of upcoming Django security releases (3.2.24, 4.2.10 and 5.0.2)\n\nDjango versions 5.0.2, 4.2.10, and 3.2.24 will be released on Tuesday,\nFebruary 6th, 2024 around 1500 UTC. They will fix one security defect\nwith severity "moderate".\n\nFor details of severity levels, see:\nhttps://docs.djangoproject.com/en/dev/internals/security/#how-django-discloses-security-issues\n
    \n
    3. \n
\n
\n
\n

Några dagar före eventuell lanseringLink to this heading#

\n
    \n

  1. När releasen närmar sig ska du titta på Trac för att se till att inga releaseblockerare finns kvar för den kommande releasen. Under exceptionella omständigheter, t.ex. för att uppfylla ett förutbestämt säkerhetsdatum, kan en release fortfarande ske med en öppen releaseblockerare. Det är upp till releasegivaren att besluta om en release ska ske med en öppen releaseblockerare eller om releasedatumet för en icke-säkerhetsrelease ska skjutas upp om så krävs.

    2. \n

  2. Kontrollera med de andra sammanslagningarna för att se till att de inte har några ändringar som inte har bekräftats för utgåvan.

    3. \n

  3. Korrekturläsa versionsinformation, inklusive att titta på online-versionen för att fånga upp eventuella brutna länkar eller reST-fel, och se till att versionsinformation innehåller rätt datum.

    4. \n

  4. Dubbelkolla att versionsnoterna nämner tidsfrister för föråldring för alla API: er som anges som föråldrade, och att de nämner eventuella ändringar i Python-versionens stöd.

    5. \n

  5. Dubbelkolla att versionsinformation-indexet har en länk till noterna för den nya releasen; detta kommer att finnas i docs/releases/index.txt.

    6. \n

  6. Om detta är en feature release, se till att översättningar från Transifex har integrerats. Detta görs vanligtvis av en separat översättningshanterare snarare än av utgivaren, men här är stegen. Den här processen är lite lång, så se till att avsätta 4-10 timmar för att göra detta och planera helst för den här uppgiften en eller två dagar före utgivningsdagen.

    \n

    Förutom att du har ett konfigurerat Transifex-konto bör tx CLI finnas tillgängligt i din PATH. Sedan kan du hämta alla översättningar genom att köra:

    \n
    Shell
    $ python scripts/manage_translations.py fetch\n
    \n

    Det här kommandot tar lite tid att köra. När det är klart ska du noggrant granska utdata efter eventuella fel och/eller varningar. Om det finns några måste du felsöka och lösa dem från fall till fall.

    \n

    De nyligen hämtade översättningarna behöver justeras manuellt. Först och främst måste värdena för PO-Revision-Date manuellt flyttas så att de är senare än POT-Creation-Date. Du kan använda ett kommando som liknar detta för att massuppdatera alla .po-filer (jämför diffen mot den relevanta stabila grenen):

    \n
    Shell
    $ git diff --name-only stable/5.0.x | grep "\\.po"  | xargs sed -ri "s/PO-Revision-Date: [0-9\\-]+ /PO-Revision-Date: $(date -I) /g"\n
    \n

    Alla nya .po-filer bör granskas manuellt och noggrant för att undvika att en ändring görs i en fil utan några nya översättningar. Det bör inte heller finnas några ändringar i ”pluralformerna”: om det finns några (vanligtvis rapporterar spanska och franska ändringar för detta) måste de återställas.

    \n

    Slutligen ska du skicka de ändrade/tillagda filerna (både .po och .mo) och skapa en ny PR som riktar sig till den stabila grenen för motsvarande utgåva (exempel PR uppdaterar översättningar för 4.2).

    \n
    7. \n

  7. Uppdatera sidan django-admin manual:

    \n
    Shell
    $ cd docs\n$ make man\n$ man _build/man/django-admin.1  # do a quick sanity check\n$ cp _build/man/django-admin.1 man/django-admin.1\n
    \n

    och sedan publicera den ändrade man-sidan.

    \n
    8. \n

  8. Om detta är ”dot zero”-utgåvan av en ny serie, skapa en ny gren från den aktuella stabila grenen i django-docs-translations-arkivet. Till exempel, när du släpper Django 4.2:

    \n
    Shell
    $ git checkout -b stable/4.2.x origin/stable/4.1.x\n$ git push origin stable/4.2.x:stable/4.2.x\n
    \n
    9. \n

  9. Skriv blogginlägget för tillkännagivandet av releasen. Du kan när som helst lägga in det i admin och markera det som inaktivt. Här är några exempel: ”Exempel på meddelande om säkerhetsrelease”, ”Exempel på meddelande om vanlig release”, ”Exempel på meddelande om pre-release”.

    10. \n
\n
\n

Några dagar innan en funktion frysesLink to this heading#

\n

Som förberedelse för alfaversionen måste katalogen /home/www/www/media/releases/A.B skapas på djangoprojektets server.

\n

Innan funktionen fryses måste en gren med inriktning på main skapas för att förbereda för nästa funktionsrelease. Den bör granskas och godkännas några dagar före frysningen, så att den kan slås samman efter att den stabila grenen har klippts. Följande punkter bör tas upp i den här grenen:

\n
    \n

  1. Uppdatera tupeln VERSION i django/__init__.py och öka till nästa förväntade utgåva (exempel commit).

    2. \n

  2. Skapa en stub release note för nästa feature release. Använd stubben från den tidigare versionen eller kopiera innehållet från den aktuella versionen och ta bort det mesta av innehållet så att endast rubrikerna kvarstår (exempel commit).

    3. \n

  3. Ta bort ... versionadded:: och ... versionchanged:: anteckningar i dokumentationen från två utgåvor sedan, liksom alla återstående äldre anteckningar. Till exempel, i Django 5.1 kommer anteckningar för 4.2 att tas bort (example commit).

    4. \n

  4. Ta bort funktioner som har nått slutet av sin utfasningscykel, inklusive deras dokument och annoteringen ...deprecated::. Varje borttagning bör göras i en separat commit för tydlighetens skull. I commit-meddelandet, lägg till ett Refs #XXXXX -- prefix som länkar till det ursprungliga ärendet där avskrivningen började om möjligt. Se till att detta noteras i avsnittet om borttagna funktioner i versionsinformation (example commit).

    5. \n

  5. Öka standard PBKDF2 iterationer i django.contrib.auth.hashers.PBKDF2PasswordHasher med cirka 20% (välj ett runt tal). Kör testerna och uppdatera de 3 misslyckade hasher-testerna med de nya värdena. Se till att detta noteras i versionsinformation (exempel commit).

    6. \n
\n

Konkreta exempel på bootstrap-grenar för tidigare funktionsutgåvor: 5.2 bootstrap, 5.1 bootstrap, 5.0 bootstrap.

\n
\n
\n
\n
\n

Frysa funktioner för uppgifterLink to this heading#

\n
    \n

  1. Ta bort tomma avsnitt från versionsinformation (exempel commit).

    2. \n

  2. Bygg versionsinformation lokalt och läs dem. Gör eventuella nödvändiga ändringar för att förbättra flödet eller fixa grammatiken (exempel commit).

    3. \n

  3. Skapa en ny stabil gren från main. Till exempel, när funktionen fryser Django 5.2:

    \n
    Shell
    $ git checkout -b stable/5.2.x upstream/main\n$ git push upstream -u stable/5.2.x:stable/5.2.x\n
    \n

    Samtidigt uppdaterar du variabeln django_next_version i docs/conf.py på den stabila utgivningsgrenen så att den pekar på den nya utvecklingsversionen. Till exempel, när du skapar stable/5.2.x, sätt django_next_version till '6.0' på den nya stabila grenen (example commit).

    \n
    4. \n

  4. Gå till sidan `Lägg till release i admin`__, skapa ett Release-objekt för den finala releasen och se till att fältet Release date är tomt, vilket markerar det som unreleased. Till exempel, när du skapar stable/5.2.x, skapa 5.2 med fältet Utgivningsdatum tomt. Om utgåvan är en del av en LTS-gren, markera det så.

    \n
    5. \n

  5. Gå till sidan `Lägg till dokumentutgåva i admin`__, skapa ett nytt DocumentRelease-objekt för det engelska språket för det nyskapade Release-objektet. Markera inte detta som standard.

    \n
    6. \n

  6. Lägg till den nya grenen i Read the Docs. Eftersom de automatiskt genererade versionsnamnen (”stable-A.B.x”) skiljer sig från de versionsnamn som används i Read the Docs (”A.B.x”), skapa ett ärende med begäran om den nya versionen.

    7. \n

  7. ”Begär den nya klassificeraren på PyPI <https://github.com/pypa/trove-classifiers/issues/29>`_. Till exempel Framework :: Django :: 5.2.

    8. \n

  8. Skapa en roadmap-sida för nästa utgåva på Trac. För att skapa en ny sida på wikin, navigera till URL:en där du vill skapa sidan och en ”Skapa den här sidan”-knapp kommer att finnas tillgänglig.

    9. \n

  9. Uppdatera den aktuella grenen under aktiv utveckling och lägg till en gren före utgivningen i Djangos utgivningsprocess på Trac.

    10. \n

  10. Uppdatera docs/fixtures/doc_releases.json JSON-fixturen för djangoproject.com, så att personer utan tillgång till produktions-DB:n fortfarande kan köra en uppdaterad kopia av dokumentsidan (exempel PR). Detta kommer att slås samman efter den slutliga utgåvan.

    11. \n
\n
\n
\n

Att faktiskt rulla ut releasenLink to this heading#

\n

OK, nu kommer den roliga delen, när vi faktiskt skickar ut en release! Om du ska skicka ut flera releaser, upprepa dessa steg för varje release.

\n
    \n

  1. Kontrollera att `Jenkins`__ är grön för den eller de versioner du släpper. Du bör förmodligen inte publicera en release förrän den är grön, och du bör se till att den senaste gröna körningen innehåller de ändringar som du publicerar.

    \n
    2. \n

  2. Städa upp i versionsinformation för denna version. Gör dessa ändringar i main och backportera till alla grenar där versionsnoterna för en viss version finns.

    \n
      \n

    1. För en funktionsutgåva, ta bort rubriken UNDER DEVELOPMENT högst upp i utgåvan, ta bort prefixet Expected och uppdatera utgivningsdatumet, om det behövs (exempel commit).

      2. \n

    2. För en patchversion, ta bort prefixet Expected och uppdatera utgivningsdatumet för alla versioner, om nödvändigt (exempel commit).

      3. \n
    \n
    3. \n

  3. En release börjar alltid från en releasegren, så du bör se till att du befinner dig på en uppdaterad stabil gren. Du bör också ha en ren och dedikerad virtuell miljö tillgänglig för varje version som släpps. Det kan till exempel vara

    \n
    Shell
    $ git checkout stable/4.1.x\n$ git pull\n
    \n
    4. \n

  4. Om detta är en säkerhetsrelease, slå samman lämpliga korrigeringar från django-security. Basera om dessa korrigeringar efter behov för att göra var och en till en vanlig commit på release-grenen snarare än en merge commit. För att säkerställa detta, sammanfoga dem med flaggan --ff-only; till exempel:

    \n
    Shell
    $ git checkout stable/4.1.x\n$ git merge --ff-only security/4.1.x\n
    \n

    (Detta förutsätter att security/4.1.x är en gren i repot django-security som innehåller de nödvändiga säkerhetsuppdateringarna för nästa utgåva i 4.1-serien)

    \n

    Om git vägrar att slå samman med --ff-only, byt till security-patch grenen och rebasera den på den gren du är på väg att slå samman den med (git checkout security/4.1.x; git rebase stable/4.1.x) och byt sedan tillbaka och gör sammanslagningen. Se till att commit-meddelandet för varje säkerhetsfix förklarar att commit är en säkerhetsfix och att ett tillkännagivande kommer att följa (exempel på säkerhetsfix).

    \n
    5. \n

  5. Uppdatera versionsnumret i django/__init__.py för utgåvan. Vänligen se notes on setting the VERSION tuple nedan för detaljer om VERSION (example commit).

    \n
      \n

    1. Om det här är ett paket som släppts före utgivningen ska du även uppdatera trove-klassificeraren ”Development Status” i pyproject.toml för att återspegla detta. En rc-förutgåva bör inte ändra trove-klassificeringen (example commit for alpha release, example commit for beta release).

      2. \n

    2. Annars, se till att klassificeraren är inställd på Development Status :: 5 - Produktion/Stabil.

      3. \n
    \n
    6. \n
\n
\n

Skapa artefakterLink to this heading#

\n\n
    \n

  1. Tagga utgåvan med hjälp av git tag. Till exempel:

    \n
    Shell
    $ git tag --sign --message="Tag 4.1.1" 4.1.1\n
    \n

    Du kan kontrollera ditt arbete genom att köra git tag --verify <tag>.

    \n
    2. \n

  2. Se till att du har ett helt rent träd genom att köra git clean -dfx.

    3. \n

  3. Kör python -m build för att generera release-paketen. Detta kommer att skapa release-artefakterna (tarball och wheel) i en dist/-katalog. För Django 5.0 eller äldre måste du köra make -f extras/Makefile istället.

    4. \n

  4. Generera hasharna för releasepaketen:

    \n
    Shell
    $ cd dist\n$ md5sum *\n$ sha1sum *\n$ sha256sum *\n
    \n
    5. \n

  5. Skapa en ”checksums”-fil, Django-<<VERSION>>.checksum.txt som innehåller hasharna och versionsinformationen. Börja med den här mallen och infoga rätt version, datum, GPG-nyckel-ID (från gpg --list-keys --keyid-format LONG), versionshanterarens GitHub-användarnamn, versions-URL och kontrollsummor:

    \n
    Text
    This file contains MD5, SHA1, and SHA256 checksums for the source-code\ntarball and wheel files of Django <<VERSION>>, released <<DATE>>.\n\nTo use this file, you will need a working install of PGP or other\ncompatible public-key encryption software. You will also need to have\nthe Django release manager's public key in your keyring. This key has\nthe ID ``XXXXXXXXXXXXXXXX`` and can be imported from GitHub, for example,\nif using the open-source GNU Privacy Guard implementation of PGP:\n\n    curl https://github.com/<<RELEASE MANAGER GITHUB USERNAME>>.gpg | gpg --import -\n\nOnce the key is imported, verify this file:\n\n    gpg --verify <<THIS FILENAME>>\n\nOnce you have verified this file, you can use normal MD5, SHA1, or SHA256\nchecksumming applications to generate the checksums of the Django\npackage and compare them to the checksums listed below.\n\nRelease packages\n================\n\nhttps://www.djangoproject.com/download/<<VERSION>>/tarball/\nhttps://www.djangoproject.com/download/<<VERSION>>/wheel/\n\nMD5 checksums\n=============\n\n<<MD5SUM>>  <<RELEASE TAR.GZ FILENAME>>\n<<MD5SUM>>  <<RELEASE WHL FILENAME>>\n\nSHA1 checksums\n==============\n\n<<SHA1SUM>>  <<RELEASE TAR.GZ FILENAME>>\n<<SHA1SUM>>  <<RELEASE WHL FILENAME>>\n\nSHA256 checksums\n================\n\n<<SHA256SUM>>  <<RELEASE TAR.GZ FILENAME>>\n<<SHA256SUM>>  <<RELEASE WHL FILENAME>>\n
    \n
    6. \n

  6. Signera checksummefilen (gpg --clearsign --digest-algo SHA256 Django-<version>.checksum.txt). Detta genererar ett signerat dokument, Django-<version>.checksum.txt.asc som du sedan kan verifiera med gpg --verify Django-<version>.checksum.txt.asc.

    7. \n
\n
\n
\n
\n

Göra utgivningen tillgänglig för allmänhetenLink to this heading#

\n

Nu är du redo att faktiskt skicka ut pressmeddelandet. För att göra detta:

\n
    \n

  1. Skapa en ny Release-post i djangoproject.com:s admin. Om detta är en säkerhetsrelease bör detta göras 15 minuter före den annonserade releasetiden, inte tidigare:

    \n
    \n
    Version

    Måste överensstämma med versionsnumret enligt definitionen i tarbollen (django-<version>.tar.gz). Exempelvis ”5.2”, ”4.1.1” eller ”4.2rc1”.

    \n
    \n
    Är aktiv

    Ställ in på False tills releasen är helt publicerad (sista steget).

    \n
    \n
    LTS

    Aktivera om utgåvan är en del av en LTS-gren.

    \n
    \n
    Datum

    Ställ in utgivningsdatumet till idag. Den här utgåvan kommer inte att publiceras förrän is_active är aktiverat.

    \n
    \n
    Artefakter

    Ladda upp filerna tarball (django-<version>.tar.gz), wheel (django-<version>-py3-none-any.whl) och checksum (django-<version>.checksum.txt.asc) som skapades tidigare.

    \n
    \n
    \n
    2. \n

  2. Testa att release-paketen installeras korrekt med hjälp av pip. Här är en enkel metod (den här testar bara att binärerna är tillgängliga, att de installeras korrekt och att migreringar och utvecklingsservern startar, men den kommer att upptäcka dumma misstag): https://code.djangoproject.com/wiki/ReleaseTestNewVersion.

    3. \n

  3. Kör `confirm-release`__ build på Jenkins för att verifiera checksummefilerna (använd t.ex. 4.2rc1 för https://media.djangoproject.com/pgp/Django-4.2rc1.checksum.txt).

    \n
    4. \n

  4. Ladda upp release-paketen till PyPI (för förhandsversioner, ladda bara upp wheel-filen):

    \n
    Shell
    $ twine upload --repository django dist/*\n
    \n
    5. \n

  5. Uppdatera den nyskapade Release i administratören i djangoproject.com och aktivera flaggan is_active.

    6. \n

  6. Tryck på ditt arbete och den nya taggen:

    \n
    Shell
    $ git push\n$ git push --tags\n
    \n
    7. \n

  7. Gör blogginlägget som tillkännager lanseringen live.

    8. \n

  8. För en ny versionsutgåva (t.ex. 4.1, 4.2), uppdatera den stabila standardversionen av dokumenten genom att vända flaggan is_default till True på lämpligt DocumentRelease-objekt i databasen docs.djangoproject.com (detta kommer automatiskt att vända den till False för alla andra); du kan göra detta med webbplatsens administratör.

    \n

    Skapa nya DocumentRelease-objekt för varje språk som har en post för den föregående utgåvan. Uppdatera djangoproject.com:s `robots.docs.txt`__-fil genom att kopiera resultatet som genereras genom att köra kommandot manage_translations.py robots_txt i den aktuella stabila grenen från `django-docs-translations repository`__. Till exempel, när du släpper Django 4.2:

    \n
    Shell
    $ git checkout stable/4.2.x\n$ git pull\n$ python manage_translations.py robots_txt\n
    \n
    9. \n

  9. Skicka meddelandet om utgåvan till e-postlistan django-announce och Django Forum. Detta bör innehålla en länk till tillkännagivandets blogginlägg.

    10. \n

  10. Om detta är en säkerhetsrelease, skicka ett separat e-postmeddelande till oss-security@lists.openwall.com. Ange ett beskrivande ämne, till exempel ”Django” plus problemets titel från versionsinformation (inklusive CVE ID). Meddelandetexten bör innehålla information om sårbarheten, t.ex. texten i blogginlägget om tillkännagivandet. Inkludera en länk till blogginlägget om tillkännagivandet.

    11. \n
\n
\n
\n

Efter lanseringLink to this heading#

\n

Du är nästan klar! Allt som återstår att göra nu är:

\n
    \n

  1. Om detta inte är en förhandsutgåva, uppdatera VERSION tupeln i django/__init__.py igen, öka till vad nästa förväntade utgåva kommer att vara. Till exempel, efter att ha släppt 4.1.1, uppdatera VERSION till VERSION = (4, 1, 2, 'alpha', 0) (example commit).

    2. \n

  2. Lägg till utgåvan i Tracs versionslista om det behövs (och gör den till standardversion genom att ändra inställningen default_version i code.djangoproject.com:s `trac.ini`__, om det är en slutlig utgåva). Den nya X.Y-versionen bör läggas till efter alfaversionen och standardversionen bör uppdateras efter ”dot zero”-versionen.

    \n
    3. \n

  3. Om detta var en slutlig version:

    \n
      \n

    1. Uppdatera den aktuella stabila grenen och ta bort grenen före utgivningen i Djangos utgivningsprocess på Trac.

      2. \n

    2. Uppdatera djangoproject.com:s nedladdningssida (exempel PR).

      3. \n
    \n
    4. \n

  4. Om detta var en säkerhetsrelease, uppdatera Arkiv över säkerhetsfrågor med detaljer om de problem som åtgärdats.

    5. \n

  5. Om detta var en förhandsversion måste översättningskatalogerna uppdateras:

    \n
      \n

    1. Skapa en ny gren från den nyligen utgivna stabila grenen:

      \n
      Shell
      git checkout stable/A.B.x\ngit checkout -b update-translations-catalog-A.B.x\n
      \n
      2. \n

    2. Se till att releaseprogrammets dedikerade virtuella miljö är aktiverad och kör följande:

      \n
      Shell
      $ cd django\n$ django-admin makemessages -l en --domain=djangojs --domain=django\nprocessing locale en\n
      \n
      3. \n

    3. Läs igenom diffen innan du skickar den och undvik att skicka ändringar till .po-filerna utan några nya översättningar (exempel commit).

      4. \n

    4. Gör en pull request mot motsvarande stabila gren och slå samman när den har godkänts.

      5. \n

    5. Vidarebefordra de uppdaterade källöversättningarna till huvud-grenen (exempel commit).

      6. \n
    \n
    6. \n

  6. Om detta var en rc pre-release, efterlys översättningar för den kommande releasen i Django Forum - Internationalization category.

    7. \n
\n
\n
\n

Anvisningar för inställning av VERSION-tupelnLink to this heading#

\n

Djangos versionsrapportering styrs av tupeln VERSION i django/__init__.py. Detta är en tupel med fem element, vars element är:

\n
    \n

  1. Större version.

    2. \n

  2. Mindre version.

    3. \n

  3. Mikroversion.

    4. \n

  4. Status – kan vara en av ”alpha”, ”beta”, ”rc” eller ”final”.

    5. \n

  5. Serienummer, för alfa/beta/RC-paket som körs i sekvens (tillåter t.ex. ”beta 1”, ”beta 2”, etc.).

    6. \n
\n

För en slutlig version är statusen alltid ”final” och serienumret är alltid 0. Ett serienummer på 0 med statusen ”alpha” kommer att rapporteras som ”pre-alpha”.

\n

Några exempel:

\n\n
","rootId":"how-to-release-django","toc":[{"title":"Översikt","anchor":"overview","children":[]},{"title":"Förutsättningar","anchor":"prerequisites","children":[]},{"title":"Uppgifter före lansering","anchor":"pre-release-tasks","children":[{"title":"10 (eller fler) dagar före en säkerhetsrelease","anchor":"or-more-days-before-a-security-release","children":[]},{"title":"En vecka före en säkerhetsrelease","anchor":"a-week-before-a-security-release","children":[]},{"title":"Några dagar före eventuell lansering","anchor":"a-few-days-before-any-release","children":[{"title":"Några dagar innan en funktion fryses","anchor":"a-few-days-before-a-feature-freeze","children":[]}]}]},{"title":"Frysa funktioner för uppgifter","anchor":"feature-freeze-tasks","children":[]},{"title":"Att faktiskt rulla ut releasen","anchor":"actually-rolling-the-release","children":[{"title":"Skapa artefakter","anchor":"building-the-artifacts","children":[]}]},{"title":"Göra utgivningen tillgänglig för allmänheten","anchor":"making-the-release-s-available-to-the-public","children":[]},{"title":"Efter lansering","anchor":"post-release","children":[]},{"title":"Anvisningar för inställning av VERSION-tupeln","anchor":"notes-on-setting-the-version-tuple","children":[]}],"breadcrumbs":[{"docname":"internals/index","title":"Djangos interna funktioner","url":"/sv/5.2/internals/"}],"prev":{"docname":"internals/git","title":"Djangos källkodsarkiv","url":"/sv/5.2/internals/git/"},"next":null,"formats":{"html":"/sv/5.2/internals/howto-release-django/","markdown":"/sv/5.2/internals/howto-release-django.md","json":"/sv/5.2/internals/howto-release-django.json"},"source":"https://github.com/django/django/blob/stable/5.2.x/docs/internals/howto-release-django.txt","official":"https://docs.djangoproject.com/sv/5.2/internals/howto-release-django/","inVersions":["6.1","6.0","5.2"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}