--- title: "Så här släpper du Django" version: 6.1 locale: sv source: https://docs.djangoproject.com/sv/6.1/internals/howto-release-django/ canonical: https://djangodocs.dev/sv/6.1/internals/howto-release-django/ --- # Så här släpper du Django 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 ändringar, men \*\*uppdatera detta dokument i enlighet med detta!** ## Översikt Det finns tre typer av releaser som du kan behöva göra: - Säkerhetsreleaser: avslöja och åtgärda en sårbarhet. Detta innebär i allmänhet två eller tre samtidiga releaser - t.ex. 3.2.x, 4.0.x och, beroende på tidpunkt, kanske en 4.1.x. - Regelbundna versionsreleaser: antingen en slutlig version (t.ex. 4.1) eller en buggfixuppdatering (t.ex. 4.1.1). - Förhandsversioner: t.ex. 4.2 alpha, beta eller rc. Den korta versionen av de inblandade stegen är: 1. Om det rör sig om en säkerhetsrelease ska du meddela säkerhetsdistributionslistan en vecka före den faktiska releasen. 2. Korrekturläsa versionsinformation, leta efter organisations- och skrivfel. Skriva ett blogginlägg och ett e-postmeddelande. 3. Uppdatera versionsnummer och skapa artefakter för releasen. 4. Skapa den nya `Release` i administratören på `djangoproject.com`. 1. Ange rätt datum men se till att flaggan `is_active` är inaktiverad. 2. Ladda upp artefakterna (tarball, wheel och checksummor). 5. Verifiera paketens signaturer, kontrollera om de kan installeras och säkerställa minimal funktionalitet. 6. Ladda upp den nya versionen/versionerna till PyPI. 7. Aktivera flaggan `is_active` för varje utgåva i administratören på `djangoproject.com`. 8. Publicera blogginlägget och skicka ut e-postmeddelandena. 9. Uppdatera versionsnummer efter release i stabila grenar. 10. Lägg till stub versionsinformation för nästa patch release i `main` och backport. Det finns många detaljer, så läs gärna vidare. > **Use the checklists app** > > To generate a checklist compiling the tasks described below as relevant to > the specific release(s) you are issuing, use the checklists app in the > [project admin](https://www.djangoproject.com/admin/checklists/). This > populates a lot of boilerplate you will need for announcements, CVE > publication, and hashes for commit messages. By using this app for preparing > security issue metadata, your peer releasers can check your entries and > consult them again in the future. See [example checklist](https://www.djangoproject.com/checklists/release/5.2.4/). ## Förutsättningar 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. - En Unix-miljö med dessa verktyg installerade (i alfabetisk ordning): - bash (version 4.0+) - git - GPG - göra - man - hashingverktyg (vanligtvis `md5sum`, `sha1sum` och `sha256sum` på Linux, eller `md5` och `shasum` på macOS) - python - A GPG key pair. Securely store the private part, and protect it with a passphrase. The public part needs to be uploaded to your GitHub account. > **Mer än en GPG-nyckel** > > Om den nyckel du vill använda inte är din standardsigneringsnyckel måste du lägga till `-u you@example.com` till varje GPG-signeringskommando som visas nedan, där `you@example.com` är den e-postadress som är kopplad till den nyckel du vill använda. - A clean Python virtual environment (Python 3.10+, pip 26.1+) to build artifacts. - Access to [Django’s project on PyPI](https://pypi.org/project/Django/) to upload binaries, ideally with extra permissions to [yank a release](https://pypi.org/help/#yanked) if necessary. Ensure your PyPI account only uses WebAuthn-based authentication factors, not TOTP (one-time codes). Create an API token following the [official documentation](https://pypi.org/help/#apitoken), and set up your `$HOME/.pypirc` file like this: *`~/.pypirc`* ```ini [distutils] index-servers = pypi django [pypi] username = __token__ password = # User-scoped or project-scoped token, to set as the default. [django] repository = https://upload.pypi.org/legacy/ username = __token__ password = # A project token. ``` - Access to [Django’s project on Transifex](https://app.transifex.com/django/django/), with a Manager role. Generate an API Token in the [user setting section](https://app.transifex.com/user/settings/api/) and set up your `$HOME/.transifexrc` file like this: *`~/.transifexrc`* ```ini [https://www.transifex.com] rest_hostname = https://rest.api.transifex.com token = # API token ``` - Tillgång till Django-administratören på `djangoproject.com` som ”Site maintainer”. - Access to create a post in the [Django Forum - Announcements category](https://forum.djangoproject.com/c/announcements/7) and to send emails to the [django-announce](https://groups.google.com/g/django-announce/) mailing list. - Tillgång till `django-security` repo i GitHub. Detta ger bland annat tillgång till distributionslistan för föranmälningar (behövs för förberedelser inför säkerhetsreleaser). - Access to the Django project on [Read the Docs](https://readthedocs.org/projects/django/). ## Uppgifter före lansering 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. ### 10 (eller fler) dagar före en säkerhetsrelease 1. Reserve one [CVE ID](https://www.cve.org/About/Overview/) per security issue as follows. (Or, if you lack CNA credentials, email `cna@djangoproject.com` with a request.) - Enable virtual environment with [cvelib](https://pypi.org/project/cvelib/) installed. - Export user information: ```shell $ export CVE_USER=@djangoproject.com CVE_ORG=DSF ``` - Reserve: ```shell $ cve --interactive reserve ``` 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. ### En vecka före en säkerhetsrelease 1. Send out pre-notification exactly **one week** before the security release. The template for that email and a list of the recipients are in the private `django-security` GitHub wiki. BCC the pre-notification recipients, and be sure to include the relevant CVE IDs. Attach all the relevant patches (targeting `main` and the stable branches), and sign the email text with the key you’ll use for the release, with a command like: ```shell $ gpg --clearsign --digest-algo SHA256 prenotification-email.txt ``` 2. [Notify django-announce](/sv/6.1/internals/security/#security-disclosure) of the upcoming security release with a general message such as: ```text Notice of upcoming Django security releases (3.2.24, 4.2.10 and 5.0.2) Django versions 5.0.2, 4.2.10, and 3.2.24 will be released on Tuesday, February 6th, 2024 around 1500 UTC. They will fix one security defect with severity "moderate". For details of severity levels, see: https://docs.djangoproject.com/en/dev/internals/security/#how-django-discloses-security-issues ``` 3. Prepare issue metadata: \* Severity \* Short description \* Reporter \* Remediator \* Reported at \* Confirmed at (usually date CVE reserved) \* CWE Problem Type \* CAPEC Impact Type \* CVSS (4.0) Score & Vector ### Några dagar före eventuell lansering 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. 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. Korrekturläsa versionsinformation, inklusive att titta på online-versionen för att [fånga upp eventuella brutna länkar](/sv/6.1/internals/contributing/writing-documentation/#documentation-link-check) eller reST-fel, och se till att versionsinformation innehåller rätt datum. 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. 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. If this is a [feature release](/sv/6.1/internals/release-process/#term-Feature-release), ensure translations from Transifex have been integrated. In addition to having a configured Transifex account, ensure that the [tx CLI](https://developers.transifex.com/docs/cli) is available in your `PATH`. You can then fetch all translations since a given date by running: ```shell $ python scripts/manage_translations.py fetch -v 1 --since= ``` To determine a good value for `--since`, check the date of the most recent commit with wording similar to `Updated translations from Transifex` and use a date a few days prior. 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. 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): ```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" ``` Lastly, commit the changed/added files (both `.po` and `.mo`) and create a new PR targeting the stable branch of the corresponding release (example [PR updating translations for 4.2](https://github.com/django/django/pull/16715)). Once merged, forward port the changes into `main` ([example commit](https://github.com/django/django/commit/cb27e5b9c0703fb0edd70b2138e3e53a78c9551d)). 7. [Uppdatera sidan django-admin manual](/sv/6.1/internals/contributing/writing-documentation/#django-admin-manpage): ```shell $ cd docs $ make man $ man _build/man/django-admin.1 # do a quick sanity check $ cp _build/man/django-admin.1 man/django-admin.1 ``` och sedan publicera den ändrade man-sidan. 8. If this is the ”dot zero” release of a new series, create a new branch from the current stable branch in the [django-docs-translations](https://github.com/django/django-docs-translations) repository. For example, when releasing Django 4.2: ```shell $ git checkout -b stable/4.2.x origin/stable/4.1.x $ git push origin stable/4.2.x:stable/4.2.x ``` 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”. #### Några dagar innan en funktion fryses Som förberedelse för alfaversionen måste katalogen `/home/www/www/media/releases/A.B` skapas på djangoprojektets server. 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: 1. Uppdatera tupeln `VERSION` i `django/__init__.py` och öka till nästa förväntade utgåva ([exempel commit](https://github.com/django/django/commit/96700c7b378c592f0b1732302c22af2fd2c87fc6)). 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](https://github.com/django/django/commit/9b5ad4056ccf9ff7ea548f72d28eb66c1b4f84cc)). 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](https://github.com/django/django/commit/9edb7833b89e811eefd94974fb987f4605b0c0d7)). 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](https://github.com/django/django/commit/f2d9c76aa7096ef3eed675b9eb824858f9dd81e5)). 5. Advance the deprecation warnings ([example commit](https://github.com/django/django/commit/0c0bda7f79a2de89a55cfcc8e60467d6588f406f)). 6. Ö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](https://github.com/django/django/commit/7288866da4dddf3705148c703421858ec19cdb78)). Concrete examples for past feature release bootstrap branches: [5.2 bootstrap](https://github.com/django/django/pull/18127), [5.1 bootstrap](https://github.com/django/django/pull/17246), [5.0 bootstrap](https://github.com/django/django/pull/16432). ## Frysa funktioner för uppgifter 1. Ta bort tomma avsnitt från versionsinformation ([exempel commit](https://github.com/django/django/commit/9e6e58bad237a80ddd5e3ab8b834cecdaad8455e)). 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](https://github.com/django/django/commit/435bdab93889dae01e71c79598edab10627cc1f9)). 3. Create a new stable branch from `main`. Be sure to fetch and update `upstream` to latest. For example, when feature freezing Django 5.2: ```shell $ git fetch upstream $ git checkout -b stable/5.2.x upstream/main $ git push upstream -u stable/5.2.x:stable/5.2.x ``` 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](https://github.com/django/django/commit/1eb62e5b622ef7fd6e0123d8bbf6662d893d5d08)). 4. Create `Release` entries for the next version in the on `djangoproject.com`. Add one for each milestone (alpha, beta, rc, and final), leaving *is active* unset to mark them as unreleased. Set target dates per the agreed schedule, and set the LTS flag if applicable. The `X.Y` roadmap page will be available at `/download/X.Y/roadmap/`. For example, when creating `stable/5.2.x`, add `Release` entries for `6.0a1`, `6.0b1`, `6.0rc1`, and `6.0`. The `6.0` roadmap can be then reviewed at . 5. Gå till sidan , skapa ett nytt `DocumentRelease`-objekt för det engelska språket för det nyskapade `Release`-objektet. Markera inte detta som standard. 6. Add the new branch to [Read the Docs](https://readthedocs.org/projects/django/). Since the automatically generated version names (”stable-A.B.x”) differ from the version names used in Read the Docs (”A.B.x”), update the Read the Docs config for the version to point to the slug `A.B.x` and set it as active. [See more details](https://github.com/readthedocs/readthedocs.org/issues/12483). 7. [Create a PR on PyPI proposing the new Trove classifier](https://github.com/pypa/trove-classifiers/pulls?q=is%3Apr+django+trove+classifier). For example `Framework :: Django :: 5.2`. 8. Update the current branch under active development and add pre-release branch in the [Django release process](https://code.djangoproject.com/#Djangoreleaseprocess) on Trac. 9. 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](https://github.com/django/djangoproject.com/pull/1446)). Detta kommer att slås samman efter den slutliga utgåvan. ## Att faktiskt rulla ut releasen 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. 1. Kontrollera att ä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. 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. 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](https://github.com/django/django/commit/1994a2643881a9e3f9fa8d3e0794c1a9933a1831)). 2. För en patchversion, ta bort prefixet `Expected` och uppdatera utgivningsdatumet för alla versioner, om nödvändigt ([exempel commit](https://github.com/django/django/commit/34a503162fe222033a1cd3249bccad014fcd1d20)). 3. Regenerate a fresh, dedicated virtual environment for the release tools using a cooldown: ```shell $ python -m pip install build twine --uploaded-prior-to=P7D ``` 4. A release always begins from a release branch, so you should make sure you’re on an up-to-date stable branch. For example: ```shell $ git checkout stable/4.1.x $ git pull ``` 5. 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: ```shell $ git checkout stable/4.1.x $ git merge --ff-only security/4.1.x ``` (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) 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](https://github.com/django/django/commit/bf39978a53f117ca02e9a0c78b76664a41a54745)). 6. Uppdatera versionsnumret i `django/__init__.py` för utgåvan. Vänligen se [notes on setting the VERSION tuple](#notes-on-setting-the-version-tuple) nedan för detaljer om `VERSION` ([example commit](https://github.com/django/django/commit/2719a7f8c161233f45d34b624a9df9392c86cc1b)). 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](https://github.com/django/django/commit/759921c8e9ad151932fc913ab429fef0a6112ef8), [example commit for beta release](https://github.com/django/django/commit/25fec8940b24107e21314ab6616e18ce8dec1c1c)). 2. Annars, se till att klassificeraren är inställd på `Development Status :: 5 - Produktion/Stabil`. ### Skapa artefakter > **Använd eventuellt hjälpskript** > > You can streamline some of the steps below using helper scripts from the > `scripts` folder: > > - Release script example run: > > ```shell > $ PGP_KEY_ID= PGP_KEY_URL= DEST_FOLDER=~/releases scripts/do_django_release.py > ``` > > - Verify the release (after artifacts were uploaded): > > ```shell > $ VERSION=5.2.1 scripts/verify_release.sh > ``` 1. Tagga utgåvan med hjälp av `git tag`. Till exempel: ```shell $ git tag --sign --message="Tag 4.1.1" 4.1.1 ``` Du kan kontrollera ditt arbete genom att köra `git tag --verify `. 2. Se till att du har ett helt rent träd genom att köra `git clean -dfx`. 3. Run `python -m build` to generate the release packages. This will create the release artifacts (tarball and wheel) in a `dist/` directory. 4. Generera hasharna för releasepaketen: ```shell $ cd dist $ md5sum * $ sha1sum * $ sha256sum * ``` 5. Skapa en ”checksums”-fil, `Django-<>.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: ```text This file contains MD5, SHA1, and SHA256 checksums for the source-code tarball and wheel files of Django <>, released <>. To use this file, you will need a working install of PGP or other compatible public-key encryption software. You will also need to have the Django release manager's public key in your keyring. This key has the ID ``XXXXXXXXXXXXXXXX`` and can be imported from GitHub, for example, if using the open-source GNU Privacy Guard implementation of PGP: curl https://github.com/<>.gpg | gpg --import - Once the key is imported, verify this file: gpg --verify <> Once you have verified this file, you can use normal MD5, SHA1, or SHA256 checksumming applications to generate the checksums of the Django package and compare them to the checksums listed below. Release packages ================ https://www.djangoproject.com/download/<>/tarball/ https://www.djangoproject.com/download/<>/wheel/ MD5 checksums ============= <> <> <> <> SHA1 checksums ============== <> <> <> <> SHA256 checksums ================ <> <> <> <> ``` 6. Signera checksummefilen (`gpg --clearsign --digest-algo SHA256 Django-.checksum.txt`). Detta genererar ett signerat dokument, `Django-.checksum.txt.asc` som du sedan kan verifiera med `gpg --verify Django-.checksum.txt.asc`. ## Göra utgivningen tillgänglig för allmänheten Nu är du redo att faktiskt skicka ut pressmeddelandet. För att göra detta: 1. Create a new `Release` entry in the [djangoproject.com’s admin](https://www.djangoproject.com/admin/releases/release/add/). If this is a security release, this should be done 15 minutes before the announced release time, no sooner: **Version** Måste överensstämma med versionsnumret enligt definitionen i tarbollen (`django-.tar.gz`). Exempelvis ”5.2”, ”4.1.1” eller ”4.2rc1”. **Är aktiv** Ställ in på False tills releasen är helt publicerad (sista steget). **LTS** Aktivera om utgåvan är en del av en LTS (Long Term Support)-gren. **Datum** Ställ in utgivningsdatumet till idag. Den här utgåvan kommer inte att publiceras förrän `is_active` är aktiverat. **Artefakter** Ladda upp filerna tarball (`django-.tar.gz`), wheel (`django--py3-none-any.whl`) och checksum (`django-.checksum.txt.asc`) som skapades tidigare. 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): . 3. Kör build på Jenkins för att verifiera checksummefilerna (använd t.ex. `4.2rc1` för ). 4. Generate a new token for this release on PyPI, and store it in `.pypirc` as shown above. 5. Upload the release packages to PyPI: ```shell $ twine upload --repository django dist/* ``` 6. On PyPI, revoke the token you just created. 7. Uppdatera den nyskapade `Release` i administratören i `djangoproject.com` och aktivera flaggan `is_active`. 8. Tryck på ditt arbete och den nya taggen: ```shell $ git push $ git push --tags ``` 9. Gör blogginlägget som tillkännager lanseringen live. 10. 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. 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 -fil genom att kopiera resultatet som genereras genom att köra kommandot `manage_translations.py robots_txt` i den aktuella stabila grenen från . Till exempel, när du släpper Django 4.2: ```shell $ git checkout stable/4.2.x $ git pull $ python manage_translations.py robots_txt ``` 11. Skicka meddelandet om utgåvan till e-postlistan [django-announce](/sv/6.1/internals/mailing-lists/#django-announce-mailing-list) och Django Forum. Detta bör innehålla en länk till tillkännagivandets blogginlägg. 12. If this is a security release, publish the CVE metadata. (The [checklist app](#checklist-generator) generates JSON for this.): ```shell $ cve publish --cve-json-file ``` 13. If this is a security release, send a separate email to `oss-security@lists.openwall.com`. Provide ”Django” plus the CVE IDs in the subject line. The message body should include the vulnerability details, for example, the announcement blog post text. Include a link to the announcement blog post. ## Efter lansering Du är nästan klar! Allt som återstår att göra nu är: 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](https://github.com/django/django/commit/a4d19953d46247ee1992b3427fe652e941524272)). 2. If this was an alpha release: 1. Add the feature release version in [Trac’s versions list](https://code.djangoproject.com/admin/ticket/versions). 2. Create a new security branch from the freshly cut stable branch. Be sure to fetch and update `upstream` to latest. For example, after the 5.2 alpha release: ```shell $ git fetch upstream $ git checkout -b security/5.2.x upstream/stable/5.2.x $ git push origin -u security/5.2.x:security/5.2.x ``` 3. Om detta var en slutlig version: 1. Update the `default_version` setting in the code.djangoproject.com’s `trac.ini` file ([example PR](https://github.com/django/code.djangoproject.com/pull/268)). 2. Update the current stable branch and remove the pre-release branch in the [Django release process](https://code.djangoproject.com/#Djangoreleaseprocess) on Trac. 3. Uppdatera djangoproject.com:s nedladdningssida ([exempel PR](https://github.com/django/djangoproject.com/pull/1444)). 4. Process the older versions that will reach End-Of-Mainstream and/or End-Of-Life support when this final release is published: 1. Ensure that the EOL versions are mentioned in the blog post. See [example announcement](https://www.djangoproject.com/weblog/2025/apr/02/django-52-released/). 2. Create a tag for the EOL stable branch and delete the stable branch. Inspect and use the `scripts/archive_eol_stable_branches.py` helper. 4. Om detta var en säkerhetsrelease, uppdatera [Arkiv över säkerhetsfrågor](/sv/6.1/releases/security/) med detaljer om de problem som åtgärdats. 5. Om detta var en förhandsversion måste översättningskatalogerna uppdateras: 1. Skapa en ny gren från den nyligen utgivna stabila grenen: ```shell $ git checkout stable/A.B.x $ git checkout -b update-translations-catalog-A.B.x ``` 2. Se till att releaseprogrammets dedikerade virtuella miljö är aktiverad och kör följande: ```shell $ cd django $ django-admin makemessages -l en --domain=django processing locale en $ django-admin makemessages -l en --domain=djangojs processing locale en ``` 3. Gör en pull request mot motsvarande stabila gren och slå samman när den har godkänts. 4. Vidarebefordra de uppdaterade källöversättningarna till `huvud`-grenen ([exempel commit](https://github.com/django/django/commit/aed303aff57ac990894b6354af001b0e8ea55f71)). 6. If this was an `alpha` pre-release, coordinate with the maintainer of [asgiref](https://pypi.org/project/asgiref/) to determine when to raise the minimum version before the final release. For the backport, add an upper bound on the next major version (example commits: [main](https://github.com/django/django/commit/df35cf578f99522dd1ba864d513be95d47bab7a5), [backport](https://github.com/django/django/commit/e5d2664908164d51d2daa46e375da8b6a93def03)). 7. If this was an `rc` pre-release, call for translations for the upcoming release in the [Django Forum - Internationalization category](https://forum.djangoproject.com/c/internals/i18n/14). ## Anvisningar för inställning av VERSION-tupeln Djangos versionsrapportering styrs av tupeln `VERSION` i `django/__init__.py`. Detta är en tupel med fem element, vars element är: 1. Större version. 2. Mindre version. 3. Mikroversion. 4. Status – kan vara en av ”alpha”, ”beta”, ”rc” eller ”final”. 5. Serienummer, för alfa/beta/RC-paket som körs i sekvens (tillåter t.ex. ”beta 1”, ”beta 2”, etc.). 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ågra exempel: - `(4, 1, 1, "final", 0)` → ”4.1.1” - `(4, 2, 0, "alpha", 0)` → ”4.2 pre-alpha” - `(4, 2, 0, "beta", 1)` → ”4.2 beta 1”