On 06/10/2015 11:54 AM, Collin Anderson wrote: > On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote: > > 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. > > > If we release every 8 months, that means we normally support deprecated > features for 2 years. If we maintained LTS compatibility, then, yes, > that would mean "supporting" the APIs for more than 5 years after > deprecation. But to be clear, most of that time it's only security > support for those APIs, and the APIs are long gone from master. Right?
Yes, that's correct. The longest a deprecated API would ever have to remain in master, under my proposal, would be from one LTS (the one it is first deprecated in) until immediately after the next LTS branches off from master. It's worth noting that I above framed "we still have to [security] support those [deprecated] APIs for [X] more years" as a negative - added maintenance cost. But we should remember that from the point of view of a user of Django like the one who just posted in django-users, who maintains large numbers of infrequently-updated Django sites, those extra years of security support for deprecated APIs could feel like a huge relief. I'm not sure how often having a deprecated API still present in a security-supported version would actually make a security fix more difficult. Obviously it's only an issue at all if there's a security problem in a closely-related area of the code. If there's a security problem in the deprecated API itself, it could result in an extra security release we wouldn't even have needed to make otherwise. I do still think that allowing third-party apps to have a simple "we support all supported Django versions" policy, without needing to implement their own compatibility wrappers, and thus hopefully allowing upgrading users to take a simpler "first update dependencies, then update Django" approach to LTS->LTS updates (instead of "first update dependencies part of the way, then update Django part of the way, then update dependencies again, then update Django again"), are all significant benefits to my/Loïc's proposal. 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/55788DB6.3010003%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
