From c8b1f22a3d88284a87d2d278d34c103d3a859c8b Mon Sep 17 00:00:00 2001 From: Sarah Boyce <42296566+sarahboyce@users.noreply.github.com> Date: Wed, 6 May 2026 17:08:20 +0200 Subject: [PATCH 1/2] Fixed duplicate target name in docs/internals/howto-release-django.txt. Also ensured that most links are anonymous to avoid implicit named references. Bug in 8ddc5b444c175c696c8197dc8f24273252b0de77. --- docs/internals/howto-release-django.txt | 48 ++++++++++++------------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt index 2ee1574ba5b0..f5b0dbb38348 100644 --- a/docs/internals/howto-release-django.txt +++ b/docs/internals/howto-release-django.txt @@ -59,12 +59,12 @@ There are a lot of details, so please read on. 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 `_. This + `project admin `__. 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 - `_. + `__. Prerequisites ============= @@ -98,12 +98,12 @@ permissions. * A clean Python virtual environment (Python 3.10+, pip 26.1+) to build artifacts. -* Access to `Django's project on PyPI `_ to +* Access to `Django's project on PyPI `__ to upload binaries, ideally with extra permissions to `yank a release - `_ if necessary. Ensure your PyPI account + `__ 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 - `_, and set up your ``$HOME/.pypirc`` file + `__, and set up your ``$HOME/.pypirc`` file like this: .. code-block:: ini @@ -124,9 +124,9 @@ permissions. password = # A project token. * Access to `Django's project on Transifex - `_, with a Manager role. Generate + `__, with a Manager role. Generate an API Token in the `user setting section - `_ and set up your + `__ and set up your ``$HOME/.transifexrc`` file like this: .. code-block:: ini @@ -139,8 +139,8 @@ permissions. * Access to the Django admin on ``djangoproject.com`` as a "Site maintainer". * Access to create a post in the `Django Forum - Announcements category - `_ and to send emails to - the `django-announce `_ + `__ and to send emails to + the `django-announce `__ mailing list. * Access to the ``django-security`` repo in GitHub. Among other things, this @@ -148,7 +148,7 @@ permissions. security release preparation tasks). * Access to the Django project on `Read the Docs - `_. + `__. Pre-release tasks ================= @@ -160,7 +160,7 @@ any time leading up to the actual release. 10 (or more) days before a security release ------------------------------------------- -#. Reserve one `CVE ID `_ per security +#. Reserve one `CVE ID `__ per security issue as follows. (Or, if you lack CNA credentials, email ``cna@djangoproject.com`` with a request.) @@ -248,7 +248,7 @@ A few days before any release have been integrated. In addition to having a configured Transifex account, ensure that the `tx - CLI `_ is available in your + CLI `__ is available in your ``PATH``. You can then fetch all translations since a given date by running: .. code-block:: shell @@ -275,7 +275,7 @@ A few days before any release 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 - `_). + `__). Once merged, forward port the changes into ``main`` (:commit:`example commit `). @@ -293,7 +293,7 @@ A few days before any release #. 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 - `_ repository. For + `__ repository. For example, when releasing Django 4.2: .. code-block:: shell @@ -355,9 +355,9 @@ cut. The following items should be addressed in this branch: <7288866da4dddf3705148c703421858ec19cdb78>`). Concrete examples for past feature release bootstrap branches: `5.2 bootstrap -`_, `5.1 bootstrap -`_, `5.0 bootstrap -`_. +`__, `5.1 bootstrap +`__, `5.0 bootstrap +`__. Feature freeze tasks ==================== @@ -403,19 +403,19 @@ Feature freeze tasks __ https://www.djangoproject.com/admin/docs/documentrelease/add/ #. Add the new branch to `Read the Docs - `_. Since the automatically + `__. 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 `__. #. `Create a PR on PyPI proposing the new Trove classifier - `_. + `__. For example ``Framework :: Django :: 5.2``. #. Update the current branch under active development and add pre-release branch in the `Django release process - `_ on Trac. + `__ on Trac. #. Update the ``docs/fixtures/doc_releases.json`` JSON fixture for djangoproject.com, so people without access to the production DB can still @@ -603,7 +603,7 @@ Making the release(s) available to the public Now you're ready to actually put the release out there. To do this: #. Create a new ``Release`` entry in the `djangoproject.com's admin - `_. If this is a + `__. If this is a security release, this should be done 15 minutes before the announced release time, no sooner: @@ -734,7 +734,7 @@ You're almost done! All that's left to do now is: #. Update the current stable branch and remove the pre-release branch in the `Django release process - `_ on Trac. + `__ on Trac. #. Update djangoproject.com's download page (`example PR `__). @@ -744,7 +744,7 @@ You're almost done! All that's left to do now is: #. Ensure that the EOL versions are mentioned in the blog post. See `example announcement - `_. + `__. #. Create a tag for the EOL stable branch and delete the stable branch. Inspect and use the ``scripts/archive_eol_stable_branches.py`` helper. @@ -787,7 +787,7 @@ You're almost done! All that's left to do now is: #. If this was an ``rc`` pre-release, call for translations for the upcoming release in the `Django Forum - Internationalization category - `_. + `__. Notes on setting the VERSION tuple ================================== From 318a316a4c86a65bede68144f9546a6056d91379 Mon Sep 17 00:00:00 2001 From: Sarah Boyce <42296566+sarahboyce@users.noreply.github.com> Date: Wed, 6 May 2026 17:10:37 +0200 Subject: [PATCH 2/2] Fixed document referenced in multiple toctrees warning in docs/internals/contributing/writing-code/index.txt. Bug in 4eb4ab4122b2b974911d4b1f935728cf35e4208c. --- .../contributing/writing-code/index.txt | 41 +++++++++++-------- 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/docs/internals/contributing/writing-code/index.txt b/docs/internals/contributing/writing-code/index.txt index a72b6c8b41bb..72758a3bbd37 100644 --- a/docs/internals/contributing/writing-code/index.txt +++ b/docs/internals/contributing/writing-code/index.txt @@ -5,16 +5,24 @@ Contributing code So you'd like to write some code, documentation or tests to improve Django? There are several ways you can help Django's development. +.. toctree:: + :hidden: + + submitting-patches + unit-tests + working-with-git + coding-style + javascript + ../accessibility + ../committing-code + Tutorials ========= The Django tutorial contains a whole section that walks you step-by-step through the contributing code process. -.. toctree:: - :maxdepth: 1 - - /intro/contributing +* :doc:`/intro/contributing` How-to guides ============= @@ -22,26 +30,23 @@ How-to guides If you already have some familiarity with the processes and principles, our documentation also contains useful guidance on specific topics: -.. toctree:: - :maxdepth: 1 - - How to submit a patch to Django for new and/or fixed behavior - How to write and run tests - How to run Django's unit tests - How to work with Git and GitHub +* :doc:`How to submit a patch to Django for new and/or fixed behavior + ` +* :doc:`How to write and run tests ` +* :doc:`How to run Django's unit tests + ` +* :doc:`How to work with Git and GitHub + ` Related topics ============== It's important to understand how we work and the conventions we adopt. -.. toctree:: - :maxdepth: 1 - - coding-style - javascript - ../accessibility - ../committing-code +* :doc:`/internals/contributing/writing-code/coding-style` +* :doc:`/internals/contributing/writing-code/javascript` +* :doc:`/internals/contributing/accessibility` +* :doc:`/internals/contributing/committing-code` We maintain a curated list of small issues suited to first-time or less experienced contributors, using the "easy pickings" filter. These are strongly