I've been working on this and wanted to raise a couple points for discussion.
How should we treat error messages in place like system checks where we have phrases like "Edit your MIDDLEWARE_CLASSES" ... of course the check can easily check both MIDDLEWARE and MIDDLEWARE_CLASSES without much effort but should we make the error message "smart" and display the version of the setting that the user is using? Alternatively, we could always reference MIDDLEWARE (the non-deprecated version) or use some variation like "MIDDLEWARE(_CLASSES)" or "MIDDLEWARE/MIDDLEWARE_CLASSES" until the deprecation period ends. Another point for discussion is whether we need to duplicate a lot of tests so we test that the middleware continue to work with both the old-style MIDDLEWARE_CLASSES and the new style MIDDLEWARE response handling. I guess a subclass of anything that uses @override_settings(MIDDLEWARE=...) that uses @override_settings(MIDDLEWARE_CLASSES=...) might work. Just putting it out there in case anyone has a better idea. On Monday, January 18, 2016 at 9:20:03 PM UTC-5, Carl Meyer wrote: > > I've updated DEP 5 with a new round of clarifications and tweaks based on > the most recent feedback: > https://github.com/django/deps/compare/62b0...master > > 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9efb8b4b-7010-4f9a-a316-250dffa2a2b6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
