I am very much in agreement with the proposal from the blogpost. A few points I want to emphasize:
- Removing the .0/.1/.2 pattern is great. Really necessary! Not only we put a lot of care in every single feature release, with the LTS being no different, but also the “.2 is LTS” is very misleading. I can confirm there is real confusion about when to upgrade Django. It is common for enterprise users to plan LTS-to-LTS jumps, but by the time they move, the target LTS is already out of its bugfix phase. The current numbering only reinforces that misunderstanding.
- From a Fellows perspective, I agree that the overall workload would likely decrease and, even if it’s stay roughly the same in terms of “time investment”, it’ll surely be simpler. Feature releases take time and attention, and even if we’d automate some steps, they still require careful coordination and add stress. Fewer releases means fewer of those coordination points.
- The 8-month cadence has always been difficult to plan around. Every year, the milestones fall in different months, making it harder to align both personal and project schedules. A fixed annual cycle would be much easier to reason about.
Now, for the “but” part: I would avoid planning release candidates and finals right before/after the new year. That period is impractical for many people. Many contributors, companies, and users are taking time off, and some organizations run end-of-year shutdowns. In the southern hemisphere it is also summer and school holidays. It would be better to avoid that window entirely.
As a concrete proposal, I think something similar to the current A.0 roadmap works well, but offset by a few weeks to stay clear of the holiday season and DjangoCon US overlap:
- Late August / Early September: alpha (feature freeze)
- Mid October: beta (non-blocking freeze, right after Python release)
- Mid November: release candidate
- Early December: final release
That keeps the rhythm familiar while making it easier for everyone to participate fully. It does not collide with major holidays (as far as I could check), and it also allows more time between Alpha and Beta, which I think we need to incorporate as well.
Another interesting data point is that targeting the “202X” release to December means that “during 202X we develop 202X”. In other words, from January to September we work on the release of the same year, which feels intuitive and aligns nicely with yearly planning.