Django 6.2 LTS release in April 2027: the last LTS and the 5.2 upgrade

Summary. Django 6.2 is scheduled for 6 April 2027, after an alpha and feature freeze on 19 January, a beta on 23 February and a release candidate on 23 March; the dates can still move. It is a long-term support (LTS) release, with mainstream support to December 2027 and security and data-loss fixes to April 2030, and the last of its kind. DEP 20, accepted by the Steering Council and announced on 10 August 2026, moves Django to one January release a year from Django 2028, numbered by year, with every release supported for three years and the separate LTS label retired. For teams on Django 5.2 LTS, whose security fixes end in April 2028, most of the work sits underneath Django: 6.2 runs only on Python 3.12 to 3.15 and needs at least PostgreSQL 16, MySQL 8.4 or MariaDB 10.11. Python 3.10 reached end of life on 1 October 2026 and 3.11 follows in October 2027. Our recommendation: change Python and the database while still on 5.2, step through 6.0 and 6.1, and land on 6.2 by mid-2027 on Python 3.14 and PostgreSQL 18, which both outlast Django 6.2's April 2030 cut-off.

About this article. It is for engineering leads running Django 5.2, 6.0 or 6.1 in production. On 7 November 2026 we checked dates, support windows, version matrices and removals against djangoproject.com, the Django release notes, DEP 20, the Python developer guide and the PostgreSQL versioning policy. The legal notes use the DPDP Act, 2023 (Gazette, 11 August 2023), the DPDP Rules, 2025 (G.S.R. 846(E), 13 November 2025), GDPR Article 32 as published, and the UK GDPR text as archived on 18 August 2026. Django 6.2 is in development, so its roadmap and notes can change. This is not legal advice, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

What is confirmed for Django 6.2, and what can still move

Sources: the 6.2 roadmap, the download page, the installation FAQ and the draft 6.2 release notes.

The draft notes already list support for the HTTP QUERY method, template tags that span several lines, django as the preferred name for django-admin (which stays as an alias), and a PostgreSQL 16 minimum. Treat anything else as unannounced, and read them again at the beta.

Is Django 6.2 really the last LTS?

Yes. The download page says 6.2 is the final release under the old policy, in which only designated LTS releases got three years, and that every feature release from Django 2028 gets the same three years. The release process documentation says there are no separate LTS releases from Django 2028, and that 6.2 is the last release on the A.B numbering and eight-month cadence.

The change comes from DEP 20, Annual Release Cycle, written by Carlton Gibson and marked Accepted. Its main points:

• One feature release a year, in about the second week of January, after an alpha in October (following the new CPython release), a beta in November and a release candidate in December.

• Calendar versioning: the DEP writes the January 2028 release as 2028.0 and its first patch as 2028.1, and the documentation calls the feature release Django 2028. It replaces what would have been 7.0.

• Every release is supported for three years (strictly, 35 months): one year of mainstream support, then two years of security and data-loss fixes.

• The LTS label is retired, because every release now carries that commitment.

• Django 5.2 LTS and 6.2 LTS keep their full advertised windows.

So 6.2 is the last A.B version, the last on the eight-month cadence, and the last given longer support than its neighbours. Node.js made a comparable move in 2026; see our Node.js annual release cadence guide.

Code that parses Django versions will notice. Django 6.2 deprecates indexing django.VERSION from its third component, unpacking it or calling len() on it, because from Django 2028 the tuple has four components: year, patch, status and iteration. Use .feature and .patch, which work under both schemes; comparisons such as django.VERSION >= (6, 2) are unaffected. RemovedInDjango70Warning becomes RemovedInDjango2028Warning, and RemovedInDjango71Warning becomes RemovedInDjango2029Warning.

Support windows for every supported Django line

Release dates come from each version's release notes and support dates from the download page. The latest patches shown were issued on 3 November 2026 and fixed six security issues.

First, 5.2 users get 12 months between the 6.2 release and their own cut-off. Second, 6.0 security support ends in April 2027, the month 6.2 ships, so 6.0 teams should move to 6.1 now and plan 6.2 for release week. Third, 6.1 ends in December 2027: a stepping stone, not a resting place.

After 6.2, every January release is an equally supported target, and Django's upgrade guide now says there is no LTS release to wait for.

The Python version matrix is the real blocker

The Django side of the matrix comes from the installation FAQ.

The 6.0 release notes confirm that 5.2 is the last series to support Python 3.10 and 3.11. That is where most 5.2 upgrades stall, because the Python version is often tied to a base image, an OS package or a managed runtime; our Python 3.11 end-of-life guide covers that move.

The end-of-life dates below come from the Python developer guide.

Read the two tables together. Django 6.2 is supported until April 2030, but Python 3.12 ends in October 2028 and 3.13 in October 2029. To keep both interpreter and framework supported for the whole window, pick Python 3.14 or 3.15. Python 3.14 has an advantage: Django 5.2 already supports it, so the interpreter and the framework can change in separate releases with separate rollbacks.

Django 6.0 also raised the floor for optional dependencies to the first versions that confirm Python 3.12 support, including psycopg 3.1.12, psycopg2 2.9.9, mysqlclient 2.2.1, Pillow 10.1.0, redis-py 5.1.0, argon2-cffi 23.1.0 and bcrypt 4.1.1. Pin at or above those before the first hop.

Database floors between 5.2 and 6.2

Each column is from that version's database notes; the 6.2 column is development documentation and can still change.

PostgreSQL is where most teams trip. Django 6.1 dropped PostgreSQL 14 because upstream support ends in November 2026, and the draft 6.2 notes drop 15 because its support ends in November 2027. Django 5.2 supports PostgreSQL 14 and higher, so move the database first and keep the framework unchanged.

Pick the target by its own end date. PostgreSQL's final releases are 12 November 2026 for version 14, 11 November 2027 for 15, 9 November 2028 for 16, 8 November 2029 for 17 and 14 November 2030 for 18. Version 16 meets Django 6.2's floor but expires 17 months before Django 6.2 does; only 18 covers the window to April 2030. See our guides to choosing a target after PostgreSQL 14 and PostgreSQL 15 end of life.

GeoDjango users have extra floors: 6.1 removes PostGIS 3.1, GEOS 3.8 and 3.9, and GDAL 3.1 and 3.2, and the 6.2 draft removes PostGIS 3.2, GDAL 3.3 and 3.4, and GEOS 3.10.

What breaks between 5.2 and 6.2

Features deprecated in 5.0 and 5.1 are removed in 6.0; features deprecated in 5.2 survive 6.0 and go in 6.1. Code that runs warning-free on 5.2 therefore meets removals in both.

Removed in Django 6.0 (deprecated in 5.0 and 5.1)

A selection from the 6.0 release notes:

Other 6.0 changes matter even if you never used deprecated APIs. DEFAULT_AUTO_FIELD now defaults to BigAutoField; a project that never set it and ignored the models.W042 warning should set DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' or makemigrations will try to alter primary keys. Custom lookups and expressions must return SQL params as a tuple. Email moved to Python's modern email API, so EmailMessage.message() returns a standard email.message.EmailMessage. Field.pre_save() may run more than once per save, so custom versions must be free of side effects.

Removed in Django 6.1 (deprecated in 5.2)

The 5.2 deprecations are few: the all argument of staticfiles.finders.find() (use find_all), the fallback to request.user when login() or alogin() receives user=None, the ordering argument of the PostgreSQL ArrayAgg, JSONBAgg and StringAgg aggregates (use order_by), and RemoteUserMiddleware subclasses that override process_request() without aprocess_request().

The 6.1 behaviour changes are likelier to fail tests. Cache keys for pages and fragments that vary on headers or arguments change, so expect cache misses after deploy. first() and last() no longer order by primary key after an empty order_by(). Combined querysets now apply default model ordering and can raise DatabaseError. Aliases are now quoted, so raw SQL that refers to mixed-case aliases may need quoting. SIGNED_COOKIE_LEGACY_SALT_FALLBACK now defaults to False, so legacy signed cookies are rejected unless you set it.

Changes already listed for Django 6.2

From the draft release notes:

• Multiline template tags: {% and %} on separate lines may now parse as a tag. A transitional 'allow_multiline_tags': False option exists and is removed in Django 2029.

• JsonResponse now defaults safe to False, and the parameter is deprecated.

• Most built-in middleware sets async_capable = False under ASGI.

• makemigrations now tracks unmanaged models, so expect new migrations for them.

• GenericIPAddressField validates IPv6 strictly; invalid values that used to save now raise ValidationError.

• Views decorated with require_safe() now also accept QUERY requests.

• The minimum asgiref rises to 3.13 and the minimum oracledb to 4.0.2.

Expect new deprecation warnings on the way: positional arguments in django.core.mail APIs and ADMINS as name-and-address tuples (6.0); the EMAIL_* settings in favour of MAILERS, select_related() with no arguments, and the salted_hmac() default moving from SHA-1 to SHA-256 in Django 2028 (6.1). Features deprecated in 6.0 and 6.1 are removed in Django 2028, and those deprecated in 6.2 in Django 2029. Fix them during the 6.2 project to avoid a second pass.

Upgrade runbook: Django 5.2 LTS to 6.2 LTS

Django's upgrade guide recommends the incremental route for an LTS-to-LTS move too: one feature release at a time, on the latest patch of each, with warnings fixed before each hop.

1. Baseline on 5.2 (November to December 2026). Move to 5.2.19 or later, run the suite with warnings on and fix every Django deprecation. Inventory Python, database, OS and package versions.

1. Change Python on 5.2. Move to Python 3.14 while still on Django 5.2. Ship it on its own.

1. Change the database on 5.2. Move to PostgreSQL 18 (or at least 16), MySQL 8.4 or later, MariaDB 10.11 or later, or SQLite 3.37 or later.

1. Hop to 6.0. Fix the removals listed above, set DEFAULT_AUTO_FIELD, update custom expressions, and run makemigrations --check to catch unexpected migrations.

1. Hop to 6.1. Fix the 5.2 removals, check raw SQL aliases and combined querysets, and plan a cache warm-up.

1. Test the 6.2 pre-releases in CI. The alpha is due on 19 January and the beta on 23 February. Report regressions while they can still be fixed.

1. Move to 6.2 in production. Take 6.2.0 after 6 April 2027 or wait for the first patch release. The hard deadline is April 2028, when 5.2 security fixes stop.

1. Clean up. Clear Django-managed caches after deploy, since pickled objects may not survive a version change, remove transitional settings and update the CI matrix.

            # Surface deprecation warnings on the current version
python -Wa manage.py test
PYTHONWARNINGS=always pytest tests --capture=no

# One hop at a time, latest patch of each series
python -m pip install "Django>=6.0,<6.1"
python manage.py makemigrations --check --dry-run
python -Wa manage.py test
          

DEP 20 points to the community django-upgrade project, whose fixers rewrite code across Django versions. It handles mechanical changes; behaviour changes such as cache keys, query ordering and template parsing still need tests.

Which path fits your situation

Deadlines come from the download page, the Python developer guide and the PostgreSQL policy.

Worked example: what the hop buys in support months

Take a 5.2 application on Python 3.11 and PostgreSQL 14. Staying put gives 17 months of framework security support (November 2026 to April 2028), but the platform fails first: PostgreSQL 14 gets its final release on 12 November 2026, and Python 3.11 ends in October 2027, six months before 5.2.

Now the planned route. Python 3.14 and PostgreSQL 18 go in on 5.2 in December 2026 and January 2027, the 6.0 and 6.1 hops land in February and March, and 6.2 reaches production in May 2027. The application then has 35 months of framework security support (May 2027 to April 2030), on a Python supported to October 2030 and a database supported to 14 November 2030. That is 24 more months than staying on 5.2 (April 2030 instead of April 2028), from one planned project instead of an emergency. The next move is to Django 2029 or later; 2029 is supported until January 2032.

Data protection notes for India, the EU and the UK

Regulators and auditors can ask about software past its security support. In India, section 8(5) of the DPDP Act requires reasonable security safeguards against a personal data breach, with a penalty of up to 250 crore rupees in the Schedule. Rule 6 of the DPDP Rules, which details those safeguards, takes effect eighteen months after publication on 13 November 2025, that is on 13 May 2027. Treat the Python 3.10 and 3.11 dates as security deadlines; our DPDP Rules compliance checklist covers the wider duties. GDPR Article 32, and the same article in the UK GDPR, require security appropriate to the risk and regular testing of those measures.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. We plan and run Django upgrades as part of application modernisation and framework upgrade work, sequencing the Python and database changes ahead of each Django hop with a CI matrix that keeps every step reversible. Talk to us at /contact-us/.

Last updated: 7 November 2026.

References

1. Django 6.2 Roadmap — Django Software Foundation

1. Download Django: supported versions and future roadmap — Django Software Foundation

1. Django is moving to an annual release cycle, 10 August 2026 — Django weblog

1. Django 6.2 release notes, under development — Django documentation

1. Databases, development version — Django documentation

1. Status of Python versions — Python Developer's Guide

1. Versioning policy — PostgreSQL Global Development Group

1. FAQ: Installation — Django documentation

1. Django's release process, development version — Django documentation

1. DEP 0020: Annual Release Cycle — Django Enhancement Proposals on GitHub

1. Django 5.2 release notes — Django documentation

1. Django 6.0 release notes — Django documentation

1. Django 6.1 release notes — Django documentation

1. Django security releases issued: 6.1.3, 6.0.10 and 5.2.19, 3 November 2026 — Django weblog

1. How to upgrade Django to a newer version — Django documentation

1. Databases, Django 5.2 — Django documentation

1. Databases, Django 6.0 — Django documentation

1. Databases, Django 6.1 — Django documentation

1. The Digital Personal Data Protection Act, 2023, Gazette of India, 11 August 2023 — Ministry of Electronics and Information Technology

1. Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), 13 November 2025 — Ministry of Electronics and Information Technology

1. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 32 — EUR-Lex

1. UK GDPR, Article 32: Security of processing, archived 18 August 2026 — legislation.gov.uk via the Internet Archive