1
Most depends by the code
The project does not have migrations at all
./manage.py makemigrations
./manage.py migrate
The project has South migrations:
you can:
-
move the south migrations in
south_migrations
or
-
totally remove the south migrations
and
./manage.py makemigrations
./manage.py migrate
if you go for option 1
you have to remember to keep uptodate your migrations with both systems (south and django). This is useful only if you want to keep django <1.7 compatibility
You have a pluggable application
This is the most complex situataion as you must preserve the south compatibility and you have to manage different version of south. Here the how to:
- move the south migrations in
south_migrations
- run ./manage.py makemigrations
- to prevent South to load the wrong migratins put the following code into
migration.__init__.py
β`
"""
Django migrations
This package does not contain South migrations. South migrations can be found
in the ``south_migrations`` package.
"""
SOUTH_ERROR_MESSAGE = """\n
For South support, customize the SOUTH_MIGRATION_MODULES setting like so:
SOUTH_MIGRATION_MODULES = {
'wfp_auth': 'wfp_auth.south_migrations',
}
"""
# Ensure the user is not using Django 1.6 or below with South
try:
from django.db import migrations # noqa
except ImportError:
from django.core.exceptions import ImproperlyConfigured
raise ImproperlyConfigured(SOUTH_ERROR_MESSAGE)
β`
0
I have done the migration from 1.6 to 1.7 on an existing project. It was fairly painless.
I renamed my old South migrations folders and let the django 1.7 migrations create a new one. (i.e. $mv appname/migrations appname/migrations.south) That will make it easier to go back to South for any reason and will keep from having a jumbled mess of both in your migrations folders.