skip to content

How does Django number and schedule its releases, and what makes an LTS release such as 5.2 different?

level: juniorimportance: should knowfreq 48%

answer

  1. A.B feature, A.B.C patch
  2. roughly every eight months
  3. the third release in a series
  4. security and data-loss fixes
  5. typically three years

basics

~20 s

Django ships a feature release (A.B) roughly every eight months and patch releases (A.B.C) as needed. Since 2.0, each X.2 release, such as 4.2 and 5.2, is long-term support: security and data-loss fixes for typically three years.

solid answer

~40 s

Django versions are `A.B` for **feature releases** and `A.B.C` for **patch releases**. Feature releases arrive on a time-based schedule, roughly every eight months, in a loose semantic-versioning pattern: `X.0`, `X.1`, `X.2`, then the next `.0`. Patch releases fix bugs and security issues and are meant to be fully compatible with their feature release, so taking the latest patch is always the advice. Since 2.0, every `X.2` has been a **long-term support** release — 4.2, then 5.2, which is the current LTS — and receives security and data-loss fixes for typically three years, while an ordinary feature release such as 6.0 or 6.1 is only covered while it is one of the two newest. That is why many teams run 5.2 in production even though 6.1 is the newest release.

code

bash · 2 lines
bash
python -m django --version        # e.g. 5.2.17: series 5.2 (LTS), patch 17
python -m pip install "Django>=5.2,<6.0"   # stay on the 5.2 LTS, take every patch

go deeper

for a junior

Recall A.B versus A.B.C, the roughly eight-month cadence, and that X.2 releases such as 4.2 and 5.2 are long-term support.

for a middle

Explain what each support window covers: patch compatibility, security and data-loss fixes for the last two feature releases, and roughly three years for an LTS.

for a senior

Show how the support windows drive when you must upgrade, how you pin to an LTS series while taking every patch, and how Python support constrains the choice.

for a principal

Relate the release model to a support policy for many services: which releases are allowed in production and how long a service may sit on one.

## Version numbers Django's documented release process defines two kinds of numbers: - **Feature release, `A.B`** — for example 5.2 or 6.1. It adds features and improvements and is *mostly* backwards compatible with the previous feature release; every exception is listed in its release notes. - **Patch release, `A.B.C`** — for example 5.2.17. It fixes bugs and security issues and is meant to be 100 % compatible with its feature release. The only allowed exception is a security or data-loss problem that cannot be fixed otherwise, and then the notes explain the upgrade. The documented answer to "should I take the latest patch release?" is always yes. Before each feature release there are alpha, beta and release-candidate builds, and each release series lives on a `stable/A.B.x` branch in the repository. ## The cadence Since Django 2.0 the numbers follow a **loose form of semantic versioning**: three feature releases per major number, and the release after an LTS bumps to the next `.0`. | Series | Releases | LTS | |---|---|---| | 4.x | 4.0, 4.1, 4.2 | 4.2 (April 2023) | | 5.x | 5.0, 5.1, 5.2 | 5.2 (April 2025) | | 6.x | 6.0 (December 2025), 6.1 (August 2026), 6.2 next | 6.2, when released | The schedule is **time-based**: a feature release roughly every eight months, with a published roadmap and a feature freeze before each one. The major number does not signal a big rewrite; it signals where deprecation shims are dropped. ## What LTS means A **long-term support** release receives **security and data-loss fixes** for a guaranteed period, typically three years. Ordinary feature releases get a shorter window: 1. The **latest feature release** gets fixes for critical problems: security issues, data loss, crashes, major bugs in new features and regressions. 2. **Security and data-loss fixes** go to `main`, the **last two feature release branches**, and **any supported LTS branch**. 3. Everything older gets nothing. So a non-LTS release like 6.0 is covered while it is one of the two newest feature releases — at the eight-month cadence, a bit over a year — whereas 5.2 keeps receiving security fixes long after 6.0 and 6.1 have shipped. ## Why teams care - **Production stability.** An LTS lets a team upgrade roughly every two years instead of every eight months. - **Third-party apps.** The deprecation policy keeps an LTS-to-LTS path smooth, and third-party authors are encouraged to support the current LTS, so packages usually work on it. - **Security obligations.** Running a release outside its window means unpatched vulnerabilities; the supported-versions table on the project's download page is the authority for exact dates. ## Pre-releases Each feature release is preceded by an **alpha**, one or more **betas** and a **release candidate**, published as `A.B aN`, `A.B bN` and `A.B rcN`. They exist so projects can test early: - Install the pre-release in a CI job, not in production. - Run the suite with deprecation warnings visible; new failures are either your code relying on something that changed, or a regression worth reporting. - A regression reported during the beta or release-candidate phase can be fixed before the final release instead of waiting for a later patch. Teams that test pre-releases rarely meet surprises on release day. ## Where the Python version fits Each feature release declares the Python versions it supports, and only the latest patch release of each Python series is officially supported. Django 5.2 supports Python 3.10 to 3.14 (3.14 from 5.2.8); Django 6.0 and 6.1 require 3.12 or newer. Choosing an LTS therefore also fixes a range of interpreters you can run. ## Common misreadings - **"6.0 is a major rewrite."** It is simply the release after the 5.2 LTS; it removes the shims deprecated in 5.0 and 5.1. - **"Patch releases can wait."** They carry the security fixes; skipping them is the riskiest way to "stay stable". - **"LTS means every bug gets fixed for three years."** Only security and data-loss fixes are guaranteed; ordinary bugs are fixed in newer releases.

  • Why pin Django as >=5.2,<6.0 rather than ==5.2.0 in a project on the LTS?
    Patch releases within 5.2 are designed to be fully compatible and carry the security fixes, so the range lets every install pick up the latest 5.2.x while blocking an accidental jump to 6.0, which removes deprecated APIs. An exact pin to 5.2.0 freezes known vulnerabilities; the lock file, not the requirement, should record the exact patch in use.
  • How long does a non-LTS release such as 6.0 receive security fixes?
    Security and data-loss fixes go to the last two feature release branches plus supported LTS branches. So 6.0 is covered while it is among the two newest feature releases, until 6.2 ships; at the eight-month cadence that is a bit over a year, far shorter than an LTS's typical three years.

LTS releases are like a car model's extended warranty: the newest model gets every improvement, but the warranty model keeps getting safety recalls for years while you decide when to trade up.

saying these in an interview costs you the question

  • Every Django feature release is supported for three years
  • Django 6.0 is a ground-up rewrite that breaks everything
  • Patch releases may add features and change APIs
  • LTS releases receive every bug fix for their whole window
  • The LTS is whichever release a team happens to standardise on