Django is moving to an annual release cycle

Django’s move to an annual release cycle simplifies the upgrade path for teams. Previously, LTS releases created a two-year gap where teams had to absorb a large batch of changes at once. Now, upgrades can be incremental, reducing the risk of compatibility breaks or delayed migrations. The change also removes the pressure to time upgrades around LTS deadlines, giving teams more flexibility to schedule maintenance during quieter periods.

The alignment with Python’s annual release cycle is the most consequential technical shift. Django’s current eight-month cycle often left it supporting Python versions that were already end-of-life, forcing maintainers to backport fixes or drop support prematurely. Under the new model, each Django release will support the three latest Python versions at launch, with the newest Python version added during the first year. This reduces the matrix of supported environments and simplifies testing for both Django core and third-party packages.

Support commitments are now uniform across all releases, which may reduce confusion but also increases the maintenance burden on the Django project. Every release will receive three years of support, including two years of security fixes after the initial bugfix window. This is a longer commitment than some non-LTS releases received previously, but it eliminates the need for teams to plan around LTS-specific schedules. The trade-off is that teams must now track annual releases more closely to stay within the support window.

The change has limited immediate impact, as the transition doesn’t begin until 2028. Teams can continue using Django 5.2 and 6.2 LTS as planned, with no changes to their support timelines. However, the shift will require adjustments in how teams plan long-term projects. For example, a project starting in 2027 may need to account for the transition to the new cycle mid-development, particularly if it relies on third-party packages that may not immediately support Django 2028.

Third-party package maintainers will need to adapt to the rolling target of three supported Django versions. The new cycle provides a clearer window for compatibility updates, but it also means packages must be tested against more frequent Django releases. The deprecation policy remains unchanged, but the longer calendar duration of support windows may extend the lifespan of deprecated features, giving maintainers more time to phase out old APIs.