skip to content

Why can't a team running Django 5.2 on Python 3.11 simply upgrade to Django 6.1, and in what order should they upgrade?

level: middleimportance: should knowfreq 36%

answer

  1. each release declares a Python range
  2. 6.0 raised the floor
  3. 5.2 is the last with 3.10 and 3.11
  4. interpreter first, on the LTS
  5. latest patch of each Python series

basics

~20 s

Django 6.0 and 6.1 support only Python 3.12, 3.13 and 3.14; 5.2 is the last series supporting 3.10 and 3.11. Upgrade the interpreter to 3.12 or newer while still on 5.2, which supports it, then upgrade Django.

solid answer

~40 s

Every Django feature release declares the Python versions it supports in its release notes, and Django 6.0 raised the floor: 6.0 and 6.1 support Python 3.12, 3.13 and 3.14, and the notes state that the 5.2.x series is the last to support 3.10 and 3.11. A service on 5.2 with Python 3.11 therefore has two upgrades to make, and they should not happen in the same step. Because 5.2 supports 3.10 through 3.14, the team first moves the interpreter to 3.12 or newer on 5.2, runs the suite and deploys; then it steps Django through 6.0 and 6.1. Django also only officially supports the latest release of each Python series, so pin a current patch of 3.12 or 3.13 rather than an old one.

code

bash · 8 lines
bash
# Step 1: new interpreter, same Django (5.2 supports 3.12)
python3.12 -m venv .venv && . .venv/bin/activate
python -m pip install "Django>=5.2,<5.3" -r requirements.txt
python -Wa manage.py test

# Step 2: Django forward, one feature release at a time
python -m pip install "Django>=6.0,<6.1" && python -Wa manage.py test
python -m pip install "Django>=6.1,<6.2" && python -Wa manage.py test

go deeper

for a junior

Recall that each Django release supports a range of Python versions and that 6.x needs Python 3.12 or newer.

for a middle

Explain the overlap: 5.2 supports 3.10 to 3.14, 6.x supports 3.12 to 3.14, so the interpreter moves first on 5.2.

for a senior

Plan the sequence with CI on the target interpreter, dependency checks, per-release Django steps and separately deployable changes.

for a principal

Align interpreter and framework lifecycles across services so no team is forced into a combined jump by an interpreter's end of support.

## Each release declares its Python range Every Django feature release has a **Python compatibility** section at the top of its release notes, and the FAQ keeps the full table. The documented rule: Django supports a Python version up to and including the first Django LTS whose security support ends after that Python's security support ends — the FAQ's example is Python 3.9 (security support ended October 2025), kept through 4.2 LTS (security support ending April 2026). Newer Python versions are sometimes added in a patch release, as 3.14 was in 5.2.8. | Django | Python versions | Notes | |---|---|---| | 4.2 LTS | 3.8 – 3.12 | 3.12 from 4.2.8; last series for 3.8 and 3.9 | | 5.0 | 3.10 – 3.12 | | | 5.1 | 3.10 – 3.13 | 3.13 from 5.1.3 | | 5.2 LTS | 3.10 – 3.14 | 3.14 from 5.2.8; last series for 3.10 and 3.11 | | 6.0 | 3.12 – 3.14 | | | 6.1 | 3.12 – 3.14 | Current release | Each notes page adds that Django "highly recommends, and only officially supports, the latest release of each series" — the newest patch of Python 3.12, not whichever 3.12 happened to be installed years ago. ## Why the jump fails A team on **Django 5.2 with Python 3.11** that bumps its requirement to 6.1 runs into a wall before any Django code changes matter: 6.1 does not support 3.11, and Django 6.x declares Python 3.12 as its minimum in its package metadata, so the installer will not install it on 3.11. A strict requirement fails to resolve; a loose one quietly stays on 5.2. Either way the upgrade stalls, and if it is combined with other changes, the cause is hard to read. ## The right order 1. **Upgrade the interpreter on the LTS.** Django 5.2 supports 3.12, 3.13 and 3.14, so move the service to one of them while Django stays the same. Run the full suite and deploy. Any failure is now about Python, not Django. 2. **Refresh dependencies** to releases that support both the new interpreter and Django 6.x. 3. **Step Django forward**: 5.2 → 6.0 → 6.1, each on its latest patch, with `python -Wa manage.py test` at every step to see the next removals, and each release's *Backwards incompatible changes* read before moving. 4. **Deploy** with the usual checks and cache clearing. The same pattern — interpreter first, on the release that supports both old and new — applied to the 4.2 to 5.2 move, where 3.10 to 3.12 were the shared range. ## Things that change with 6.0 besides Python - Deprecations added in 5.0 and 5.1 are removed in 6.0; those added in 5.2 are removed in 6.1. - Some defaults change; for example, `DEFAULT_AUTO_FIELD` defaults to `BigAutoField` in 6.0, which matters for projects that never set it. A clean `-Wa` run on the latest 5.2 patch covers the removals; the defaults need reading. ## Checking what you actually run Before planning, confirm the facts on every environment, since laptops, CI and production often differ: 1. `python --version` and `python -m django --version` in the deployed image, not only locally. 2. The interpreter in the CI matrix and in the container base image. 3. Whether the lock file resolves the same Django and dependency versions everywhere. Mismatches here are the usual reason an upgrade "works on my machine" and fails in the pipeline. ## How to plan it - Put the interpreter version in the same place as the Django pin (lock file, container base image, CI matrix) so the two are reviewed together. - Run CI on the target Python early, even before deploying it, to find incompatible packages. - Keep 5.2 in production while the 6.x work proceeds; the LTS keeps receiving security fixes, so there is no forced deadline — only the growing size of the eventual jump.

  • Why upgrade Python while still on Django 5.2 instead of together with the move to 6.0?
    5.2 supports both 3.11 and 3.12, so it is the one Django version where only the interpreter changes. Failures in that step are about Python or packages, not Django. Combining the two means every failure could come from either, and a rollback reverts both. Separate steps are smaller, bisectable and independently deployable.
  • What does 'only officially supports the latest release of each series' mean in Django's Python compatibility notes?
    For each supported Python minor version, such as 3.12, Django tests and supports the newest patch release of that series. Running an old 3.12.x may work but is outside what Django promises, so the interpreter should be kept on current patch releases just like Django itself.

saying these in an interview costs you the question

  • Django 6.1 still supports Python 3.10 and 3.11
  • Django 5.2 cannot run on Python 3.12
  • Upgrade Python and Django in the same step to save a release cycle
  • Any patch release of a Python series is equally supported
  • Python support only matters for new projects, not upgrades