In 1.10, Django changed the way middleware works. Several of the

built-in methods were coalesced together into a callable that processes

the request, delegates to other middleware, and then processes the

response. In order to distinguish between the invocation methods, they

renamed the setting from MIDDLEWARE_CLASSES to MIDDLEWARE.
For most of our middleware classes, we can just inherit from the new

MiddlewareMixin class. This allows middleware classes to work

correctly no matter which version of Django they're using.
The big wrinkle here was in extension middleware. To start with, I'm

pretty sure that nobody is using it (our documentation claims that the

middleware attribute should be a list of module paths to the

middleware classes to match the setting, but the implementation was

expecting a list of classes themselves). More importantly, the way that

they were processed (instantiating the classes at init time and then

calling the old process_* methods) wouldn't work with new-style

middleware.
I've added some detection to figure out whether each entry in the list

is old- or new-style, and then depending on what the setting is, do the

right thing. We can run old-style middleware with the new setting, but

can't run new-style middleware with the old setting. Appropriate

warnings have been added in these situations. This includes new test

cases to check that the various different combinations run the

middleware as expected.

Ran unit tests.
Used djblets middleware (logging, settings) with Review Board.