A Cleaner Cadence for a Mature Framework
The Django project has accepted a proposal to move from its previous mix of short-lived feature releases and long-term-support releases to a single annual cycle. Every feature release will now be supported for three years: one year of full bug fixes followed by two years of security and data-loss fixes.
What Changes for Users
The familiar “LTS” label disappears because every release carries the same commitment. Teams no longer face a two-year gap that forces a large jump. Instead they can upgrade one year at a time inside a rolling three-version support window. Third-party packages also gain a clearer target: three supported versions are always available.
Carlton Gibson announced the change on the official Django weblog. The decision reflects the framework’s maturity. Most innovation now happens in the ecosystem of packages rather than in the core, so a slower, more predictable release train reduces friction without slowing progress.
Practical Consequences
Projects that previously tracked the latest feature release will simply continue doing so, now with a longer security window. Projects that stayed on LTS versions will find that the next annual release already offers the same length of support they used to wait for. The migration path becomes incremental rather than a periodic big-bang upgrade.
The new policy takes effect with the forthcoming release train. Django’s documentation and download pages will be updated to reflect the simplified support matrix.