Hello, With the current system of release branches, the release schedule doesn’t affect much the rhythm at which Django accrues changes. For a given community of contributors and team of committers, the amount of changes in a new release is roughly proportional to its development time.
(We could have a discussion about backwards-compatibility but I’ll save it for another day.) However the release schedule affects Django’s backwards-compatibility guarantees. Given the two-releases deprecation system, backwards-incompatible changes that require end users to adapt their code can happen in two time the duration of the release cycle. Now, upgrading a project means: 1. checking which dependencies already support the newer Django version 2. finding a solution for the other dependencies (contributing, forking, replacing, etc.) 3. reading the release notes and trying to figure out what changes are needed 4. upgrading and running tests, both automated and manual 5. fixing whatever problems the tests reveal 3. and 5. are proportional to the amount of backwards-incompatible changes or, given my assumptions, to the amount of time since the last upgrade. 1., 2. and 4. are more ore less fixed costs. Upgrading a pluggable application is the same story with an extra complication. Most applications support multiple version of Django at once. With the two-release deprecation cycles, in practice, it’s quite easy to support consecutive releases N and N + 1, especially since we silenced PendingDeprecationWarning. It’s usually possible to support N and N + 2 if you accept the loud DeprecationWarning. However supporting N and N + 3 can be very hard. If N + 1 introduces significant changes (e.g. app-loading), N doesn’t contain anything to help with the transition and N + 3 completes the deprecation cycle by removing the code that helped the transition. That’s the situation maintainers of third-party apps find themselves in since we introduced LTS releases: until recently, 1.4, 1.6 and 1.7 were supported; now, 1.4, 1.7 and 1.8. As a consequence, I think that releases have a fairly high cost for our users and an even higher cost for maintainers of Django's open-source ecosystem. Each release starts the cycle of users asking maintainers to support the newer Django version, but maintainers don’t like the idea of dropping the oldest version yet, and supporting everything with the same code is complicated… That’s why I think that shorter release cycles will do more harm than good. I believe that 9 months is a reasonable compromise. Historically we aimed for 9 months and did 12. Then we aimed for 6 and did 9. With the fellowship, we know that we can reach the goal we set. I still think that 9 months is the right goal. If we wanted to make more frequent major releases, I think we would have to: - either tighten our rules on backwards-compatibility, which would hurt the pace of progress; - or keep three releases under security support, which I’m not looking forward to. Neither of these options seem better than a 9 month release cycle. -- Aymeric. > On 4 avr. 2015, at 14:30, Tim Graham <timogra...@gmail.com> wrote: > > Now that Django 1.8 is released, I wanted to bump this thread for discussion > so we can hopefully ratify this schedule or modify it based on feedback. In > particular, I heard a concern that a six month release schedule may be too > often for the community. On the other hand, I think smaller releases would > make incremental upgrades easier. > > One difficulty could be if third-party packages try to support every version > since the last LTS (this seemed to be common with 1.4). A 6 month release > schedule would mean 5 versions of Django until the next LTS, instead of 3 as > we had since 1.4, so more `if DJANGO_X_Y` conditionals. One idea is that > third-party packages could declare their own "LTS" versions (if needed) and > drop support for older versions more freely in future development. > > On Wednesday, March 11, 2015 at 8:13:11 PM UTC-4, Tim Graham wrote: > With the release of 1.8 coming up, it's time to think about 1.9! I've > suggested some dates below. The schedule is similar to the intervals we used > for 1.8 with the final release date planned for about 6 months after 1.8 > final (barring unforeseen delays, 1.8 will be released about 7 months after > 1.7). Please voice any thoughts or concerns. With this schedule it seems that > any GSoC work would likely be included in 2.0. If you have any big features > planned, please add them here: > https://code.djangoproject.com/wiki/Version1.9Roadmap > <https://code.djangoproject.com/wiki/Version1.9Roadmap> > > July 20 - Alpha (feature freeze) > August 21 - Beta (only release blockers fixed after this) > September 18 - RC (string freeze for translations) > October 2 - Final > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at http://groups.google.com/group/django-developers > <http://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/0df00068-112f-4e98-9201-78d6ba9ef97c%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/0df00068-112f-4e98-9201-78d6ba9ef97c%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/B7173A62-2393-4D2E-8E85-D1CE17C77D0C%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
