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 can just be fixed. >
+1 > But the two examples you cite have an edge case with behavior that is > unspecified in the documentation. The next question I would ask in those > cases is "Can I imagine a scenario in which someone is intentionally > taking advantage of the current behavior - it's not just hiding an error > in their code? How likely is that scenario? How reasonable is their use > case? And if we conclude that there may be people out there with a > reasonable use case for the current behavior, how hard would it be for > them to change their code to continue working as-is, if Django's > behavior is changed?" > Again, +1. Another example where we changed immediately was when we disallowed select_related in automatic transaction mode, in 1.6.3. In that case, we had a stronger argument: 1.6 changed automatic mode, so that code which had been correct suddenly gained a potential for data-corruption. Shai.
