Re: Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

2015-12-21 Thread Cristiano Coelho
Hello, the select_related change was a really good one, after updating I found around 3 or 4 queries that had a typo in select_related which was obviously never noticed before. In this project finding those errors was not complicated at all, but I believe that on a big project that also has poo

Re: Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

2015-12-21 Thread Shai Berger
On Monday 21 December 2015 20:45:26 Carl Meyer wrote: > > Obviously the first question is whether the behavior in question is > documented. If it is, then a deprecation path is definitely required. On > the other hand, if the current behavior contradicts the documentation, > then it's a bug and ca

Re: Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

2015-12-21 Thread Carl Meyer
Hi Tim, On 12/21/2015 08:09 AM, Tim Graham wrote: > 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

Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

2015-12-21 Thread Tim Graham
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