I wanted to learn about squashmigrations so this is an example on how we could use it.
Migrations are no longer relevant once they have been executed, so they are basically a bunch of dead code. Migrations can also get quite complex on larger refactoring. Getting rid of dead complex code seems like a good idea.
On the other hand, this breaks installations that have not executed these old migrations. In other words: It makes updating more complicated. And even though it feels strange, keeping those old migrations doesn't actually hurt.
If you checkout this branch and run migrateall it will not work. Instead, you first have to checkout the "squash migrations" commit and run migrateall there. This will store the squashed migrations in the database so that django later knows that they do not need to be executed again.
Theoretically, we could squash all migrations on every release and then cleanup on the next release. But should we? I am torn.
The django docs recommend not to do it:
You are encouraged to make migrations freely and not worry about how many you have
Still I feel like we should cleanup early refactoring before our first "real" release. But maybe not adding migrations at all until !1058 (merged) was already sufficient for that goal.