---
title: "Comment publier Django"
version: 6.1
locale: fr
source: https://docs.djangoproject.com/fr/6.1/internals/howto-release-django/
canonical: https://djangodocs.dev/fr/6.1/internals/howto-release-django/
---
# Comment publier Django

Ce document explique comment est réalisée une publication de Django.

**Veuillez s’il-vous-plaît garder ces instructions à jour si vous procédez à des modifications !** La clé ici est d’être descriptif et non pas normatif, sentez-vous donc libre de simplifier ou de faire d’autres changements dans la procédure, mais alors **mettez à jour ce document en fonction !**

## Aperçu

Il peut être nécessaire d’effectuer trois différents types de publications :

- Publications de sécurité : annonce et résolution d’une vulnérabilité. Cela implique généralement deux ou trois publications simultanées – par ex. 3.2.x, 4.0.x et selon le timing, peut-être une 4.1.x.
- Publications de version normale : soit une publication finale (par ex. 4.1) ou une mise à jour corrective (par ex. 4.1.1).
- Prépublications : par ex. 4.2 alpha, bêta ou rc.

La version courte des étapes à suivre est :

1. S’il s’agit d’une publication de sécurité, prénotifier la liste de distribution de sécurité une semaine avant la publication effective.
2. Relire les notes de publication, particulièrement en ce qui concerne leur organisation et leur formulation. Écrire un brouillon d’article de blog et de courriel d’annonce.
3. Changer les numéros de version and créer les artefacts de version.
4. Créer la nouvelle `Release` dans l’admin de `djangoproject.com`.

   1. Définir la date prévue mais assurez-vous que le champ `is_active` est désactivé.
   2. Upload the artifacts (tarball, wheel, and checksums).
5. Vérifier les signatures du ou des paquets, contrôler s’ils peuvent être installés et s’assurer de leur fonctionnement minimal.
6. Envoyer la ou les nouvelles versions au serveur PyPI.
7. Enable the `is_active` flag for each release in the admin on
   `djangoproject.com`.
8. Publier l’article de blog et envoyer le courriel d’annonce.
9. Update version numbers post-release in stable branch(es).
10. Add stub release notes for the next patch release in `main` and backport.

Il y a beaucoup de détails, accrochez-vous !

> **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/).

## Prérequis

Certains prérequis sont nécessaires avant de commencer. S’il s’agit de votre première publication, vous devriez vous coordonner avec un autre publicateur afin de régler ces différentes exigences et écrire à la liste de diffusion des opérateurs pour demander l’accès et les permissions requises.

- Un environnement Unix avec les outils suivants installés (par ordre alphabétique) :

  - bash (version 4.0+)
  - git
  - GPG
  - make
  - man
  - des outils de hachage (typiquement `md5sum`, `sha1sum` et `sha256sum` sur Linux, ou `md5` et `shasum` sur 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.

  > **Plus d’une clé GPG**
  >
  > Si la clé que vous souhaitez utiliser n’est pas votre clé de signature par défaut, vous devrez ajouter `-u vous@example.com` à chaque commande de signature GPG affichée ci-dessous, où `vous@example.com` est l’adresse de courriel associée à la clé que vous allez utiliser.
- 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
  ```
- Un accès à l’interface d’administration Django de `djangoproject.com` comme « mainteneur de site ».
- 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.
- Un accès au dépôt `django-security` sur GitHub. Parmi d’autres choses, cela donne accès à la liste de distribution de prénotification (nécessaire pour les tâches de préparation des publications de sécurité).
- Access to the Django project on [Read the Docs](https://readthedocs.org/projects/django/).

## Tâches de pré-publication

Il faut s’occuper de quelques tâches avant même de commencer le processus de publication en tant que tel. Celles-ci commencent environ une semaine avant la publication ; la plupart peuvent être réalisées à n’importe quel moment précédant la publication réelle.

### 10 jours (ou plus) avant une publication de sécurité

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=<user-email>@djangoproject.com CVE_ORG=DSF
     ```
   - Reserve:

     ```shell
     $ cve --interactive reserve <quantity>
     ```
2. Produisez le ou les correctifs appropriés (et privés) en utilisant `git format-patch`, un pour la branche `main` et un pour chaque branche stable soumise à cette correction.

### Une semaine avant une publication de sécurité

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. [Notifiez django-announce](/fr/6.1/internals/security/#security-disclosure) au sujet de la mise à jour de sécurité à venir avec un message général du genre :

   ```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

### Quelques jours avant toute publication

1. À l’approche de la publication, surveillez Trac pour vous assurer qu’aucun ticket bloquant ne reste pour la prochaine publication. Dans des circonstances exceptionnelles, comme par exemple le respect d’une date de publication de sécurité prédéterminée, une publication peut tout de même avoir lieu avec des tickets bloquants ouverts. Le publicateur est responsable de la décision de publier même si des tickets bloquants sont encore ouverts ou de différer la date de publication si nécessaire, quand celle-ci n’est pas liée à la sécurité.
2. Se coordonner avec les autres fusionneurs pour être sûr qu’ils n’ont pas de commits en attente pour cette publication.
3. Relire les notes de publication, y compris la version en ligne pour [détecter tout lien cassé](/fr/6.1/internals/contributing/writing-documentation/#documentation-link-check) ou erreur reST, et s’assurer que les notes de publication contiennent la bonne date.
4. Revérifier que les notes de publication mentionnent la planification d’obsolescence pour toute API signalée comme obsolète et qu’elles mentionnent tout changement dans la prise en charge des versions de Python.
5. Revérifier que le sommaire des notes de publication contienne un lien vers les notes de la nouvelle publication ; le fichier concerné est `docs/releases/index.txt`.
6. If this is a [feature release](/fr/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=<some date>
   ```

   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.

   Cette commande prend du temps à s’exécuter. Lorsqu’elle a terminé, inspectez soigneusement le résultat au cas où des erreurs ou avertissements y figureraient. S’il y en a, vous devrez explorer pour résoudre ces problèmes au cas par cas.

   Les traductions récemment récupérées ont besoin d’ajustement manuel. Tout d’abord, les valeurs `PO-Revision-Date` doivent être manuellement mises à jour pour être postérieures à `POT-Creation-Date`. Vous pouvez utiliser une commande telle que celle-ci pour mettre à jour en lot tous les fichiers `.po` (comparez le diff avec la branche stable concernée) :

   ```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. [Mettez à jour la page de manuel de django-admin](/fr/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
   ```

   puis faites le commit de la page de manuel modifiée.
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. Écrivez l’article de blog d’annonce de la publication. Vous pouvez l’écrire dans le site d’administration tout en le marquant comme inactif. Voici quelque exemples : [exemple d’annonce de publication de sécurité](https://www.djangoproject.com/weblog/2013/feb/19/security/), [exemple d’annonce de publication normale](https://www.djangoproject.com/weblog/2012/mar/23/14/), [exemple d’annonce de pré-publication](https://www.djangoproject.com/weblog/2012/nov/27/15-beta-1/).

#### A few days before a feature freeze

In preparation for the alpha release, the directory
`/home/www/www/media/releases/A.B` must be created on the djangoproject
server.

Before the feature freeze, a branch targeting `main` must be created to
prepare for the next feature release. It should be reviewed and approved a few
days before the freeze, allowing it to be merged after the stable branch is
cut. The following items should be addressed in this branch:

1. Update the `VERSION` tuple in `django/__init__.py`, incrementing to the
   next expected release ([example commit](https://github.com/django/django/commit/96700c7b378c592f0b1732302c22af2fd2c87fc6)).
2. Create a stub release note for the next feature release. Use the stub from
   the previous feature release or copy the contents from the current version
   and delete most of the contents leaving only the headings
   ([example commit](https://github.com/django/django/commit/9b5ad4056ccf9ff7ea548f72d28eb66c1b4f84cc)).
3. Remove `.. versionadded::` and `.. versionchanged::` annotations in the
   documentation from two releases ago, as well as any remaining older
   annotations. For example, in Django 5.1, notes for 4.2 will be removed
   ([example commit](https://github.com/django/django/commit/9edb7833b89e811eefd94974fb987f4605b0c0d7)).
4. Remove features that have reached the end of their deprecation cycle,
   including their docs and the `.. deprecated::` annotation. Each removal
   should be done in a separate commit for clarity. In the commit message, add
   a `Refs #XXXXX --` prefix linking to the original ticket where the
   deprecation began if possible. Make sure this gets noted in the removed
   features section in the release notes ([example commit](https://github.com/django/django/commit/f2d9c76aa7096ef3eed675b9eb824858f9dd81e5)).
5. Advance the deprecation warnings ([example commit](https://github.com/django/django/commit/0c0bda7f79a2de89a55cfcc8e60467d6588f406f)).
6. Increase the default PBKDF2 iterations in
   `django.contrib.auth.hashers.PBKDF2PasswordHasher` by about 20%
   (pick a round number). Run the tests, and update the 3 failing
   hasher tests with the new values. Make sure this gets noted in the
   release notes ([example 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).

## Feature freeze tasks

1. Remove empty sections from the release notes ([example commit](https://github.com/django/django/commit/9e6e58bad237a80ddd5e3ab8b834cecdaad8455e)).
2. Build the release notes locally and read them. Make any necessary change
   to improve flow or fix grammar ([example 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
   ```

   At the same time, update the `django_next_version` variable in
   `docs/conf.py` on the stable release branch to point to the new
   development version. For example, when creating `stable/5.2.x`, set
   `django_next_version` to `'6.0'` on the new stable branch
   ([example commit](https://github.com/django/django/commit/1eb62e5b622ef7fd6e0123d8bbf6662d893d5d08)).
4. Create `Release` entries for the next version in the [admin](https://www.djangoproject.com/admin/releases/release/add/) 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 <https://www.djangoproject.com/download/6.0/roadmap/>.
5. Go to the [Add document release page in the admin](https://www.djangoproject.com/admin/docs/documentrelease/add/), create a new
   `DocumentRelease` object for the English language for the newly created
   `Release` object. Do not mark this as default.
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. Update the `docs/fixtures/doc_releases.json` JSON fixture for
   djangoproject.com, so people without access to the production DB can still
   run an up-to-date copy of the docs site
   ([example PR](https://github.com/django/djangoproject.com/pull/1446)).
   This will be merged after the final release.

## Production réelle de la nouvelle version

Voilà, il s’agit maintenant de la partie sympa où nous allons effectivement produire la publication ! Si vous produisez **plusieurs publications**, répétez ces étapes pour chaque publication.

1. Vérifiez que [Jenkins](https://djangoci.com) est vert pour la ou les versions que vous allez produire. Vous ne devriez probablement pas produire de version tant que ce n’est pas vert, et vous devez vous assurer que la dernière exécution en vert inclue les modifications que vous allez publier.
2. Nettoyez les notes de cette publication. Faites les modifications dans `main` et rétroportez-les dans toutes les branches où les notes de publication de cette version apparaissent.

   1. Pour une publication majeure, enlevez l’en-tête `UNDER DEVELOPMENT` au sommet des notes de publication, enlevez le préfixe `Expected` et mettez à jour la date de publication si nécessaire ([commit d’exemple](https://github.com/django/django/commit/1994a2643881a9e3f9fa8d3e0794c1a9933a1831)).
   2. Pour une publication corrective, enlevez le préfixe `Expected` et mettez à jour la date de publication de toutes les publications, si nécessaire ([commit d’exemple](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. S’il s’agit d’une mise à jour de sécurité, fusionnez les correctifs appropriés à partir de `django-security`. Rebasez ces correctifs si nécessaire pour que chacun d’entre eux soit un commit simple sur la branche de publication plutôt qu’un commit de fusion. Pour s’assurer de cela, fusionnez-les avec le drapeau `--ff-only`; par exemple :

   ```shell
   $ git checkout stable/4.1.x
   $ git merge --ff-only security/4.1.x
   ```

   (Cela suppose que `security/4.1.x` est une branche du dépôt `django-security` contenant les correctifs de sécurité nécessaires pour la prochaine publication de la série 4.1).

   Si Git refuse de fusionner avec `--ff-only`, revenez dans la branche des correctifs de sécurité et rebasez-la sur la branche dans laquelle vous allez effectuer la fusion (`git checkout security/4.1.x; git rebase stable/4.1.x`), puis retournez dans la branche initiale et effectuez la fusion. Vérifiez que le message de commit de chaque correction de sécurité explique qu’il s’agit bien d’un correctif de sécurité et qu’une annonce va suivre ([exemple de commit de sécurité](https://github.com/django/django/commit/bf39978a53f117ca02e9a0c78b76664a41a54745)).
6. Mettez à jour le numéro de version dans `django/__init__.py` pour la publication. Veuillez lire les [notes sur la définition du tuple VERSION](#notes-on-setting-the-version-tuple) ci-dessous pour plus de détails sur le format de `VERSION` ([commit d’exemple](https://github.com/django/django/commit/2719a7f8c161233f45d34b624a9df9392c86cc1b)).

   1. If this is a pre-release package also update the « Development Status »
      trove classifier in `pyproject.toml` to reflect this. An `rc`
      pre-release should not change the trove classifier ([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. Sinon, assurez-vous que le classificateur est défini à `Development Status :: 5 - Production/Stable`.

### Building the artifacts

> **Optionally use helper scripts**
>
> You can streamline some of the steps below using helper scripts from the
> `scripts` folder:
>
> - Release script example run:
>
> ```shell
> $ PGP_KEY_ID=<key-id> PGP_KEY_URL=<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. Placez une étiquette sur la publication avec `git tag`. Par exemple :

   ```shell
   $ git tag --sign --message="Tag 4.1.1" 4.1.1
   ```

   Vous pouvez contrôler votre travail en exécutant `git tag --verify <tag>`.
2. Assurez-vous d’avoir une arborescence parfaitement propre en exécutant `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. Générez les empreintes des paquets à publier :

   ```shell
   $ cd dist
   $ md5sum *
   $ sha1sum *
   $ sha256sum *
   ```
5. Créez un fichier « checksums », Django-\<\<VERSION\>\>.checksum.txt\` contenant les empreintes et les informations de publication. Commencez avec ce modèle et insérez la version correcte, la date, l’identifiant de clé GPG (provenant de `gpg --list-keys --keyid-format LONG`), le nom d’utilisateur de responsable de version GitHub, l’URL de publication et les sommes de contrôle :

   ```text
   This file contains MD5, SHA1, and SHA256 checksums for the source-code
   tarball and wheel files of Django <<VERSION>>, released <<DATE>>.

   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/<<RELEASE MANAGER GITHUB USERNAME>>.gpg | gpg --import -

   Once the key is imported, verify this file:

       gpg --verify <<THIS FILENAME>>

   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/<<VERSION>>/tarball/
   https://www.djangoproject.com/download/<<VERSION>>/wheel/

   MD5 checksums
   =============

   <<MD5SUM>>  <<RELEASE TAR.GZ FILENAME>>
   <<MD5SUM>>  <<RELEASE WHL FILENAME>>

   SHA1 checksums
   ==============

   <<SHA1SUM>>  <<RELEASE TAR.GZ FILENAME>>
   <<SHA1SUM>>  <<RELEASE WHL FILENAME>>

   SHA256 checksums
   ================

   <<SHA256SUM>>  <<RELEASE TAR.GZ FILENAME>>
   <<SHA256SUM>>  <<RELEASE WHL FILENAME>>
   ```
6. Signez le fichier de sommes de contrôle (`gpg --clearsign --digest-algo SHA256 Django-<version>.checksum.txt`). Cela produit un document signé, `Django-<version>.checksum.txt.asc` que vous pouvez ensuite vérifier avec `gpg --verify Django-<version>.checksum.txt.asc`.

## Rendre la ou les publications publique(s)

Vous êtes maintenant prêt à publier les nouveaux paquets. Pour cela :

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**

     Must match the version number as defined in the tarball
     (`django-<version>.tar.gz`). For example: « 5.2 », « 4.1.1 », or « 4.2rc1 ».

   **Is active**

     Set to False until the release is fully published (last step).

   **LTS**

     Enable if the release is part of an LTS (Long Term Support)
     branch.

   **Dates**

     Set the release date to today. This release will not be published until
     `is_active` is enabled.

   **Artifacts**

     Upload the tarball (`django-<version>.tar.gz`), wheel
     (`django-<version>-py3-none-any.whl`), and checksum
     (`django-<version>.checksum.txt.asc`) files created earlier.
2. Test that the release packages install correctly using `pip`. Here’s one
   simple method (this just tests that the binaries are available, that they
   install correctly, and that migrations and the development server start, but
   it’ll catch silly mistakes):
   <https://code.djangoproject.com/wiki/ReleaseTestNewVersion>.
3. Lancez la construction [confirm-release](https://djangoci.com/job/confirm-release/) sur Jenkins pour vérifier les fichiers de sommes de contrôle (par ex. utilisez `4.2rc1` pour <https://media.djangoproject.com/pgp/Django-4.2rc1.checksum.txt>).
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. Update the newly created `Release` in the admin in `djangoproject.com`
   and enable the `is_active` flag.
8. Poussez votre travail et la nouvelle étiquette :

   ```shell
   $ git push
   $ git push --tags
   ```
9. Écrivez l’article de blog annonçant que la publication est en ligne.
10. Pour une publication majeure (par ex. 4.1, 4.2), mettez à jour la version stable par défaut de la documentation en activant le drapeau `is_default` sur l’objet `DocumentRelease` approprié de la base de données `docs.djangoproject.com` (cela va automatiquement mettre à `False` ce drapeau pour toutes les autres instances) ; vous pouvez faire cela par le moyen du site d’administration.

    Créez des objets `DocumentRelease` pour chaque langue ayant déjà un tel objet pour une version précédente. Mettez à jour le fichier [robots.docs.txt](https://github.com/django/djangoproject.com/blob/main/djangoproject/static/robots.docs.txt) de djangoproject.com en copiant le résultat obtenu en lançant la commande `manage_translations.py robots_txt` de la branche stable actuelle dans le [dépôt  django-docs-translations](https://github.com/django/django-docs-translations). Par exemple, lors de la publication de Django 4.2 :

    ```shell
    $ git checkout stable/4.2.x
    $ git pull
    $ python manage_translations.py robots_txt
    ```
11. Publiez l’annonce de publication sur la liste de diffusion [django-announce](/fr/6.1/internals/mailing-lists/#django-announce-mailing-list) ainsi que sur le forum Django. Cette annonce doit contenir un lien vers l’article de blog de l’annonce.
12. If this is a security release, publish the CVE metadata. (The
    [checklist app](#checklist-generator) generates JSON for this.):

    ```shell
    $ cve publish <cve-number> --cve-json-file <path-to-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.

## Après la publication

Vous êtes presque au bout ! Tout ce qui reste à faire est :

1. If this is not a pre-release, update the `VERSION` tuple in
   `django/__init__.py` again, incrementing to whatever the next expected
   release will be. For example, after releasing 4.1.1, update `VERSION` to
   `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. S’il s’agit d’une nouvelle version majeure :

   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. Mettez à jour la page de téléchargement de djangoproject.com ([PR d’exemple](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. S’il s’est agi d’une publication de sécurité, mettez à jour [Archive des issues de sécurité](/fr/6.1/releases/security/) avec les détails sur les problèmes corrigés.
5. S’il s’agit d’une prépublication, les catalogues de traduction doivent être mis à jour :

   1. Make a new branch from the recently released stable branch:

      ```shell
      $ git checkout stable/A.B.x
      $ git checkout -b update-translations-catalog-A.B.x
      ```
   2. Ensure that the release’s dedicated virtual environment is enabled and
      run the following:

      ```shell
      $ cd django
      $ django-admin makemessages -l en --domain=django
      processing locale en
      $ django-admin makemessages -l en --domain=djangojs
      processing locale en
      ```
   3. Make a pull request against the corresponding stable branch and merge
      once approved.
   4. Forward port the updated source translations to the `main` branch
      ([example 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).

## Notes sur la définition du tuple VERSION

La version de Django est contrôlée par le tuple `VERSION` dans `django/__init__.py`. C’est un tuple à cinq éléments, contenant :

1. La version majeure.
2. La version mineure.
3. La version micro.
4. Le statut, qui peut-être « alpha », « beta », « rc » ou « final ».
5. Le numéro de série, dans le cas des versions alpha/beta/RC qui se font suite (autorisant, par exemple, « beta 1 », « beta 2 », etc.).

Pour une version finale, le statut est toujours « final » et le numéro de série 0. Un numéro de série à 0 avec le statut « alpha » est signalé comme une « pre-alpha ».

Quelques exemples :

- `(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 »