Django drops the LTS release for an annual cycle, and the upgrade gap goes with it

Django is changing how it ships. On August 10 the project’s Steering Council accepted DEP 20, retiring the long-term support (LTS) release and moving Django to a single feature release each year. The mechanics matter, but the more consequential part is what the change removes: the LTS gap that has quietly left many projects running unsupported versions because the jump to the next safe release looked too big to schedule.

What actually changed

Starting in January 2028, Django will publish one feature release a year instead of the current roughly eight-month cadence. Version numbers move to calendar versioning in a YYYY.N form, so the first release under the new model is Django 2028.0 (the release that would otherwise have been Django 7.0), followed by monthly patch releases such as 2028.1 and then Django 2029.0 the following January. Every feature release now carries the same commitment: three years of support, structured as one year of mainstream bug fixes followed by two years of security and data-loss fixes. Three feature releases are supported at any given time, the current one under mainstream support and the two prior years under extended support. The “LTS” label goes away entirely, because every release is now what LTS used to be.

Nothing changes before then. The 6.x line continues on the existing schedule, and Django 6.2 LTS (April 2027) keeps its support window through April 2030. This is a planned transition, not a break in the middle of the current cycle.

Why the old cycle created upgrade debt

Under the eight-month cycle, Django alternated short-lived feature releases with occasional LTS releases, and the two behaved very differently. Non-LTS releases got a short support window, LTS releases got a long one. In practice many teams pinned to an LTS and then faced an intimidating LTS-to-LTS jump that skipped two years of changes at once. Others sat on releases that had already fallen out of support. The result was that a meaningful share of installs ran versions no longer receiving security fixes, not because upgrading was hard technically but because the cadence made the safe path feel like a cliff.

Calendar versioning targets a second, quieter problem. A number like 4.2 tells you little about how old a release is or how far behind you are. A number like 2028.0 does. For teams auditing their stack, that legibility is much of the point.

What it means for working teams

For application teams, the practical change is that every yearly release is now a safe place to stand for three years, and the annual rhythm makes upgrades a routine calendar item rather than a periodic migration project. LWN’s coverage put the benefit plainly: there is no more LTS gap and no racing a deadline to jump two years of changes at once. The trade-off is that staying current now means a yearly upgrade cadence rather than parking on an LTS for its full life, so teams that preferred long stretches between upgrades will feel more frequent, if smaller, moves.

For third-party package maintainers, the change gives a cleaner target. Supporting the three currently supported Django releases becomes a stable, rolling window that shifts predictably each January, which should shrink the matrix of versions a library feels obliged to test against. The proposal also aligns Django’s cadence with Python’s own annual release schedule and holds each release to three supported Python versions, which cuts the number of interpreter versions any given Django release has to carry.

The trade-off worth watching

The change is not the only obvious answer. In LWN’s comments one reader pointed to Symfony’s model, with more frequent minor releases alongside major versions and longer security windows, as a different way to balance freshness and stability. Django’s bet is that predictability and a uniform three-year guarantee will do more to keep users on supported versions than a menu of release types did. Whether that holds is an empirical question the first calendar-versioned releases will begin to answer. The near-term signals to watch are the final releases of the 6.x line and how cleanly the 2028.0 transition lands, since the whole case rests on more teams staying current once the LTS gap is gone.

Sources cited

1. Django is moving to an annual release cycle (Django Weblog) www.djangoproject.com
2. DEP 20: Annual release cycle, accepted (Django DEPs) github.com
3. Django moves to an annual release cycle (LWN.net) lwn.net