James Bennett wrote:
Perhaps that's why, in both the 1.2 alpha release notes and the draft
for the final 1.2 notes, it's listed under a big heading titled
"backwards-incompatible changes".
As we say in Russia "Gee, I didn't notice the elephant" :-).
I still think it would be useful to add an e
On Tue, Feb 16, 2010 at 4:39 AM, Ivan Sagalaev
wrote:
> It's not the question of responsibility. We're changing a minor version
> which is supposed to be backwards compatible. If a site will break in this
> case people won't go looking for some responsible person they'll just blame
> Django for br
Luke Plant wrote:
This case is slightly different because it is down to an interaction
of a changed default setting with working code, but there will always
be cases like that, and I think it is much better for developers to
remember the general principle that they are responsible for whatever
On Monday 15 February 2010 09:20:28 Ivan Sagalaev wrote:
> Hello everyone!
>
> A couple of days ago we've noticed a (potentially big) backwards
> incompatibility that can bite users upgrading from 1.1 to 1.2.
>
> CSRF doc encourages users to enable CsrfViewMiddleware that will
> check all POST r
Hello everyone!
A couple of days ago we've noticed a (potentially big) backwards
incompatibility that can bite users upgrading from 1.1 to 1.2.
CSRF doc encourages users to enable CsrfViewMiddleware that will check
all POST requests for csrf_token and then suggests to alter all HTML
forms to