If we dropped 1.8 deprecated features in 2.0, then it would require libraries to add conditional code to support both the old and new ways of doing something. The idea is that a third-party app wouldn't need to make any updates (except those needed to accommodate for backwards incompatible changes) until the next LTS release.
The idea is *not* to suggest apps should try to support two LTS releases. Making that easy on Django's end would require keeping deprecated features in Django significantly longer than this proposal. See Carl's post in the thread where we discussed the deprecation cycle changes: https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote: > > 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no longer > supported]. > 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer supported]. > 2.0 - Aug. 2016: No features dropped. > 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]. > > This is awesome. > > So why not to have 2.0 drop features features deprecated in 1.8? If the > replacement pattern/feature is available in 1.8, the 3rd party app should > be able to use the new feature to stay compatible, right? If anything I'd > like to see us hold off on dropping features deprecated in 1.9 until after > the LTS to help people migrate between LTSs. > > Thanks, > Collin > > > On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote: >> >> I put together a draft proposal in the form of a potential >> djangoproject.com blog post. I've enabled commenting in case you have >> minor cosmetic comments, but please keep discussion about the content of >> the proposal itself on this mailing list. Also, please let me know of any >> additional questions or complaints that you'd like to see addressed in the >> last section. >> >> The overview is: >> * New major release every 8 months >> * New long-term support release every 2 years. LTS releases continue to >> be supported with security updates for 3 years. >> * Adjust the deprecation policy to make it easier for third-party apps to >> support all versions back to the last LTS. >> >> >> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing >> >> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote: >>> >>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote: >>>> >>>> How about >>>> >>>> a 8 month release cycle and having a LTS in every two years and >>>> supporting the old LTS atleast 3 years from the release date? there will >>>> be >>>> 3 version between two LTS. >>>> >>> >>> Interesting. I like the idea of having predictable release dates. >>> >> -- 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/acf37866-7a8c-4077-a399-0627acddd885%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
