Django Evolution now uses the new dependency graph to determine the

order in which evolutions and migrations will apply, allowing projects

to ensure that, for instance, certain migrations apply after certain

evolutions, or vice-versa.
Starting out, it builds up the migration plans and computes evolution

state as it did before, and then it provides this to EvolutionGraph.

To keep the same rough default ordering that we had in 2.0, the

"pre"-stage migration plan is added to the graph first, followed by

evolutions/model creations, and then the "post"-stage migration plan.

This takes advantage of the insertion-based ordering that

EvolutionGraph uses by default for any items that don't otherwise

define explicit dependencies.
It then fetches the dependency-ordered list of batches of migrations,

evolutions, and model creations that should be applied and further

processes and groups them into a new set of batches for execution.
All this work leads to a carefully-ordered set of operations that can be

performed, in the correct order, to upgrade a database no matter which

upgrade methods an app is using and in which order they need to be

applied (so long as there are evolutions hinting at the correct order).
This is the culmination of the last several weeks and 25 commits worth

of work. There's still work to add documentation, and there may be

refinements on the process, but as of now this appears to be feature

complete.

Unit tests pass across all versions of Python and Django, across all

databases.
Performed a new install of Review Board 4.0 (with dependency information

added) successfully on MySQL and Postgres. This wasn't possible before

outside of SQLite.
Also performed an upgrade from Review Board 3.0 to 4.0 successfully.