This is the last major release of South, as migrations have been rolled into Django itself as part of the 1.7 release, and my efforts are now concentrated there. South will continue to receive security updates but no feature updates will be provided.
An upgrade path is provided for those moving from South to the new-style migrations; more details are available in the Django documentation. The migrations framework in 1.7 is based on South but with significant design and stability improvements that were only possible after modifying Django itself; the result is a world-class schema migration system.
I’d like to thank all the contributors to South over the years for their work in helping me keep everything together, and all the South users for making a small side project I started in 2007 (eight years ago at the time of writing) into one of the most popular Django apps of all time.
None (it would be a really nasty time to introduce these)
As part of providing a migration path for authors of third-party apps and libraries for Django, South will now first look for migrations in the south_migrations directory, and then fall back to the migrations directory if this is not found.
This is intended to alleviate the namespace clash between South and Django migrations; prior to this, both were looking for a directory called migrations, and so it was impossible to ship a third-party app with support for both South and Django 1.7.
The recommendation is that you move your South migrations into the south_migrations directory (existing users will not notice the change if they upgrade South first), and then start a new set of Django 1.7 migrations in a migrations directory (the default).
If your users are stubborn and refuse to upgrade South, they may instead change the SOUTH_MIGRATION_MODULES setting for your app to point to the new south_migrations directory.
This does obviously entail keeping two sets of migrations around, but the two systems have some fundamental differences that mean it was impossible to have one solution that would work across both codebases. At the end of the day, this allows you to interact with each migrations system on its own level, rather than some third abstraction layer that would probably be the worst of both worlds.