The idea here is that if you know which migrations were in version 2.0.3
of your project and which were in version 2.0.4
then setA - setB
gives you the list of migrations you need to undo.
Django migrations give you a directed acyclic graph which describes how to get from the current database state to the target state. But there is no mechanism by which you can perform tasks like revert all the migrations that just ran in the last deployment
.
Here is a quick recipe for batching Django migrations to allow you to do things like that.
Before you tag your project you do: