Django moves to an annual release cycle [LWN.net]

The Django Python web-framework project has announced that it has accepted an annual release cycle proposal. This means that the project is moving from a somewhat complicated schedule that interspersed short-lived feature releases and long-term-support (LTS) releases to a simpler annual cycle where each release is supported for three years.

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.

This will take effect with the upcoming Django 2028 release, expected in January 2028.

to post comments

When to update? I guess this helps tell us

Posted Aug 10, 2026 17:30 UTC (Mon) by cerebus (subscriber, #162576) [Link] (2 responses)

Scoping updates to time rather than features always feels a bit forced to me, but it's better than how a major point release often gets treated: too scary to update, put it off again. As a Django dev at work, it will probably help to keep us on a regular release cycle.

When to update? I guess this helps tell us

Posted Aug 10, 2026 19:12 UTC (Mon) by burki99 (subscriber, #17149) [Link]

I really like the Symfony release cycle:

There are Symfony minor version (e.g. 7.1, 7.2, 7.3) every half year which are backwards compatible, so you can always move among these.
There is a Symfony major version (e.g. 6.0, 7.0, 8.0) every two years.
The LTS minor version x.4 is released at the same time and identical to the next major version (x+1).0 except removal of deprecations.
So you can move to LTS, start working on addressing all deprecations, and once you cleared those, move up to the next major branch.
LTS gets 3 years of bug fixes and 4 years of security support. So there is no rush to move from one major version to the next.
https://symfony.com/doc/current/contributing/code/release...

When to update? I guess this helps tell us

Posted Aug 12, 2026 19:25 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

One big benefit of time-based is that if someone misses the "train", it's pretty well scoped when the next one leaves. With feature-based, once a release date is announced, all kinds of "new" work springs up like weeds wanting to get released with everything else. When this "new" work ends up breaking CI, taking review resources away, or whatever (CI is much better now, but still not perfect), the release inevitably slips. The key to doing time-based is sketching out a timeline for the next release too so that when you say "not this release, maybe the next one", there's still a hazy, but discernible, point in the future to act as a goal.