Hi Tim, On 05/08/2015 08:28 AM, Tim Graham wrote: > 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.
I think this change would definitely help. Just to play devil's advocate for a moment, I do think there would be some value in going one step further and making it easier for widely-used third-party apps to actually straddle two LTS releases. Philosophically it seems reasonable that, as a third-party project author, I ought to be able to have a simple supported-versions policy of "support every currently-supported Django version", without having to work around removed APIs. This always used to be possible (without contortions) before the introduction of the LTS releases. Also, having to "sync" the upgrades of your dependencies with your upgrade of Django (because there is no version of the dependency that supports both the old and new Django version) can combinatorially explode the complexity of the upgrade. (We saw this play out with Django 1.6->1.7 and South->migrations.) It's much better if you can do the two upgrades separately (by which I mean, "have a working version of your project that passes all its tests in between each step"). OTOH, even your proposal makes it possible to do them separately; you'd just have to first upgrade Django to the last release before the next LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the newer version that supports both 2.0 and 2.1, and then finally upgrade to 2.1. And there is a significant added maintenance cost to my proposal compared to yours. Dropping deprecated APIs in the release after an LTS means we still have to support those APIs for three more years (possibly for four or five years after they were first deprecated). Dropping them _in_ the LTS release shortens that window drastically. So all in all it probably makes more sense to try your less-drastic proposal first. > By the way, the current feedback from the survey regarding the release > schedule: > Every 6 months 519 > 31.7% > Every 8 months 265 16.2% > Every 9 months 301 18.4% > Every 12 months 505 30.9% Wow, it would be hard to design a less-helpful result :-) It seems that we have a bimodal distribution: there's the "release early and often" camp and the "don't release very often, upgrading is too hard" camp, and they are roughly evenly balanced. 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/554CE066.5080405%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
