Django's Steering Council has accepted the Django Enhancement Proposal DEP 20 to move Django to an annual release cycle. From January 2028, Django will make one feature release a year, giving every feature release the LTS-level three years of support, and version numbers will carry the feature release year: Django 2028, then Django 2029, and so on.

Better Python support

Python releases annually, each October. Django's eight-month cycle hasn't fit that well: LTS releases carried a wide Python matrix, including versions long past their upstream end-of-life.

Under the new cycle, each Django version supports the three latest Python versions at release, and picks up the new Python version during its first year. Django's support window ends in step with its oldest supported Python.

Every release is an LTS

Every feature release gets three years of support: one year of mainstream bugfixes, then two years of security and data-loss fixes. The "LTS" label is retired — every feature release now carries that same, unique commitment.

No more LTS gap: no racing a deadline to jump two years of changes at once. Upgrade one year at a time, whenever suits you within the support window. Three versions are supported at any time, giving third-party packages a clear, rolling target.

API stability and deprecation policies are unchanged — deprecation periods actually get longer in calendar terms.

Transition timeline

Django 2028 will be the first release under the new cycle.

Nothing changes before 2028. Support commitments for Django 5.2 LTS and 6.2 LTS stand as made.

Read the DEP

DEP 20 has the full specification and the reasoning behind each decision. Thanks to everyone who took part in the discussion, and to the Steering Council for its consideration.