Upgrade path for re-usable apps with South AND django 1.7 migrations

Question

Or: can Django 1.7 users still use South?

I'm the maintainer of a re-usable app. Our policy is to always support the latest two versions of Django. We have an extensive set of South migrations and, we want to support the new Django 1.7 migration system going forward.

What I'm confused with is how I can allow developers to use my app with both Django 1.6 (and South) and Django 1.7 (new migrations).

The Django Documentation recommends just deleting all the pre-existing South migrations. But this is not an option, since I need to keep them around for my Django 1.6 users.

The closest to an upgrade path I could come up with, is not use the new migration system until I drop support for Django <1.7 in my app (so when Django 1.8 comes out). But what about the naming clash with the migrate command? Both South and the new system use python manage.py migrate to run migrations. So Django 1.7 users can't use South anymore?

Answer 1

South 1.0 provides the solution. It will look first in a south_migrations/ folder and fallback to migrations/. So in your case of third-party libraries needing to support older and newer Djangos: move South files to south_migration/ and create new 1.7 migrations in migrations/.

• South 1.0 release notes
• Django docs have also added this information

South cannot be used with Django 1.7, but that's not a problem for end users. They either use new Django or older Djangos with South 1.0. There won't be a South 2.0, which was going to backport new 1.7-style migrations. Also @Ondrej's answer is correct just it was written before South 1.0 was released so the truth back then (mere months ago) consisted only of workarounds.

Answer 2

There's are settings both in Django (MIGRATION_MODULES) and in South (SOUTH_MIGRATION_MODULES) which let you specify module with migrations. So you have 2 options:

• put Django 1.7 migrations to new folder and let Django 1.7 users know they should set MIGRATION_MODULES to given folder.
• move South migrations to new folder and let South users know a new version of your app is backwards incompatible and they should set SOUTH_MIGRATION_MODULES to given folder in order to continue using it.

Here's an article describing more or less the same. Plus an app that already made changes to support both South and Django 1.7.