I'd like to ask for opinions about whether or not deprecations are more useful than making small backwards incompatible changes when they move Django in a direction toward unhiding probable developer error.
An example from a past release is the validation of fields in select_related() [1]. This was done as a backwards-incompatible change in 1.8: invalid fields immediately raised an error. Would you rather a change like that go through the normal deprecation cycle (pending deprecation, deprecation, error)? My reasoning against it is that it continues to hide probable errors in new and old code (especially in the first release since PendingDeprecationWarning isn't loud by default) and the cost for users of fixing existing code is likely low compared to the overhead of a deprecation cycle in Django. Did anyone find this was not the case in their own projects? The question came up again with the behavior of the default error views silencing TemplateDoesNotExist when a custom template name is specified [2]. [1] https://docs.djangoproject.com/en/dev/releases/1.8/#select-related-now-checks-given-fields [2] https://code.djangoproject.com/ticket/25697 -- 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/3d60212a-1379-4a0e-ac6a-3b9b41e5c82a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
