Do we need to make it easy to support two LTS releases at once? For example, at this point in time I expect projects to drop 1.4 support when adding 1.8 support, not try to support both given that 1.4 will be EOL in < 6 months. Assuming the answer is no, practically, it might mean keeping around the deprecation shims added in an LTS release a bit longer than usual -- otherwise no change to the current 2 version deprecation if we adopted the 8 month schedule:
1.8 - April 2015 - LTS 1.9 - Dec. 2015 - (drop features deprecated in 1.7) [1.7 no longer supported] 2.0 - Aug. 2016 - 2.1 - April 2017 - LTS (drop features deprecated in 1.8, 1.9) [1.9 no longer supported, third party apps can update to support 2.0 as a minimum version; 1.8 users should use an old version of the third-party app for the ~1 year until 1.8 is unsupported] 2.2 - Dec. 2017 - (drop features deprecated in 2.0) [2.0 no longer supported] I think this change would be worth it. By the way, the current feedback from the survey regarding the release schedule: Every 6 months519 31.7%Every 8 months26516.2%Every 9 months30118.4%Every 12 months 505 30.9% On Friday, May 8, 2015 at 12:20:24 AM UTC-4, Tai Lee wrote: > > This sounds good. But will it significantly slow down the rollout of new > features into Django that require deprecation? Also, could features that > are deprecated in an LTS be dropped in the next non-LTS release? e.g. if > 1.8 still had a feature that was deprecated in 1.5, could it finally be > removed in 1.9? > > > On Friday, May 8, 2015 at 1:53:59 AM UTC+10, Carl Meyer wrote: >> >> On 05/07/2015 08:53 AM, Tim Graham wrote: >> > I think there is some merit to reconsidering the deprecation schedule >> as >> > Anssi suggests. What I have seen is that most third-party apps didn't >> > consider dropping support for the previous LTS (1.4) until the next LTS >> > (1.8) was released. This meant that all these projects had to implement >> > their own compatibility shims (instead of using Django's) once they >> > wanted to add support for Django 1.6+ because the compatibility shims >> > for deprecated features in 1.4 were dropped in Django. This resulted in >> > ugly code with lots of conditional version branches, etc. I'll keep >> > thinking about this as we decide the release schedule going forward. >> >> I agree with this. I think by far the biggest thing we could do to make >> it easier to go from LTS to LTS is to make it easier for third-party >> apps to support two LTS releases at once. Guaranteeing that no API which >> is un-deprecated in one LTS will be removed until after the following >> LTS would make that massively easier. >> >> Carl >> >> >> -- 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/005377e8-efb3-4009-99ee-0c2431b820dc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
