Django End-of-Life Dates —
Official EOL Schedule for Every Version

Django 4.2 LTS reached end of life on April 7, 2026 — six weeks ago. If you're running 4.2 in production, you are no longer receiving security patches from the Django project. Django 5.1 reached EOL even earlier, in December 2025. Between those two versions, a significant portion of the production Django ecosystem is now running unsupported software.

This page is the single reference for Django end-of-life dates across every version — with EOL Risk Scores™, Django's LTS vs standard release explained, the Python compatibility matrix, and a plain-English upgrade guide.

Complete Django EOL Schedule

Django releases a new feature version approximately every eight months. Each version receives active support for eight months, then moves to security-only support for another eight months — a total of 16 months per standard release. LTS releases receive three full years of support, making them the right choice for most production deployments.

LTS vs Standard Releases — What It Means for EOL

Django's release model creates two very different support timelines, and choosing the wrong track is the most common reason teams end up on EOL software unexpectedly.

Standard releases — Django 4.0, 4.1, 5.0, 5.1, 6.0 — receive 16 months of support total. Eight months of active development, then eight months of security-only patches. They move fast. Django 5.1 shipped in August 2024 and was EOL by December 2025 — 16 months later. If you're not actively tracking the release calendar, a standard release can slip past EOL before you notice.

LTS releases — Django 3.2, 4.2, 5.2, and the upcoming 7.2 — receive three full years of support. Eight months active, then 28 months of security-only patches. These are the versions production deployments should anchor to. The LTS release is always the third feature release in a major series — the x.2 release.

Django 4.2 LTS — EOL April 7, 2026

Django 5.1 — EOL December 3, 2025

Django 5.2 LTS — Supported Until April 2028

Django 6.0 — Current Standard Release

Python Compatibility Matrix

Django and Python have intertwined EOL timelines. Running Django on an EOL Python version compounds your security exposure — you're getting two layers of unpatched CVE risk. This matrix shows which Python versions are supported by each Django version.

How to Upgrade Safely

• 01
  Check your current version Run python -m django --version or check your requirements.txt / pyproject.toml. Also check your Python version with python --version — you may need to upgrade Python alongside Django.
• 02
  Read the release notes for every version between yours and the target Django maintains detailed release notes with explicit "deprecated features removed" sections. Going from 4.2 to 5.2 means reading the 5.0, 5.1, and 5.2 release notes. The Django project's notes are thorough — use them. Pay particular attention to removed features, changed default settings, and database migration behavior changes.
• 03
  Run Django's system checks After updating Django in your environment, run python manage.py check --deploy. This surfaces deprecated API usage, security misconfigurations, and compatibility issues before they hit production. Address every warning before deploying.
• 04
  Update third-party packages Your Django upgrade will often require updating django-rest-framework, celery, django-allauth, and other ecosystem packages that declare Django version compatibility. Run pip list --outdated and update packages that have dropped support for your current Django version.
• 05
  Run your full test suite before and after Django upgrades are usually smooth but behavioral changes in the ORM, template engine, or middleware can surface in tests that wouldn't catch them in manual testing. If you don't have a test suite, this upgrade is the forcing function to start one.
• 06
  Upgrade Python if needed Django 5.2 LTS requires Python 3.10+. If you're on Python 3.8 or 3.9, you need to upgrade Python first. The safest sequence: upgrade Python to 3.12, validate your app, then upgrade Django to 5.2. Doing both simultaneously increases the blast radius if something breaks.
• 07
  Consider extended support if you need more time If your 4.2 migration will take longer than a few sprints, commercial extended support from specialist vendors provides continued security patches for EOL Django versions including 3.2, 4.0, 4.2, 5.0, and 5.1. This buys documented, auditable coverage while your migration is in progress.