When adding a migration on master, I discovered that the new-style
migrations were strongly out of sync; Django wanted to create new
migrations for almost every app. That was surprising given that no model
changes were made since building that set of migrations.

The issue is that they were built with Django 1.7 RC2, and we've since
switchted to RC3. If I'd have to guess, I'd say the following issue is
responsible for it:
2da20379c0

As beta 1 is only a day old and it doesn't cause major headaches, it was
decided that it's easiest to release a new set of migrations. And pray
to the gods of Python that we won't have a similar situation again
before the Django migrations framework stabilises.

Native migrations created with Python 2 differ from ones created with
Python 3. More importantly, they failed when used in Python 3, but not
vice versa. This is caused by field names being marked as byte strings
when using Python 2.

This rewrites the native migrations, which probably isn't a bad thing
either, because they were created with a pre-RC2 version of Django, and
Django 1.7 has since seen a few more migration-related fixes.

It's likely Django now does the correct thing and generates Python 2 and
3 compatible migrations under both versions of Python.

To create test databases, the Django test runner calls the 'migrate'
management command, and I think the current Nose test runner calls
'syncdb', which under Django 1.7 is aliased to 'migrate'.

This command inspects the migration graph to figure out the migrations
to run. So it inspects the migrations that ship with Oscar. Some of them
depend on the partner or customer migrations. The test suite swaps out
those apps. Until now, the command then couldn't find the initial
migrations and would fail with a dependency error.

As far as I can tell, there's no good way to just call what used to be
"syncdb" and ignore migrations completely. So for now, we will have to
create migrations for the test apps that replace Oscar.