mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-31 09:41:08 +00:00
Code Issues 32 Releases Wiki Activity

[1.7.x] Fixed #23127: south_migrations note in docs

Browse Source
This commit is contained in:
Andrew Godwin
2014-07-29 10:10:31 -07:00
parent 3deddc2fdf
commit cc875e94cf
1 changed files with 17 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/topics/migrations.txt
View File

@@ -599,7 +599,7 @@ Upgrading from South
--------------------
If you already have pre-existing migrations created with
`South 0.x <http://south.aeracode.org>`_, then the upgrade process to use
`South <http://south.aeracode.org>`_, then the upgrade process to use
``django.db.migrations`` is quite simple:
* Ensure all installs are fully up-to-date with their migrations
@@ -616,3 +616,19 @@ of foreign keys; in this case, ``makemigrations`` might make more than one
initial migration, and you'll need to mark them all as applied using::
python manage.py migrate --fake yourappnamehere
Libraries/Third-party Apps
~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are a library or app maintainer, and wish to support both South migrations
(for Django 1.6 and below) and Django migrations (for 1.7 and above) you should
keep two parallel migration sets in your app, one in each format.
To aid in this, South 1.0 will automatically look for South-format migrations
in a ``south_migrations`` directory first, before looking in ``migrations``,
meaning that users' projects will transparently use the correct set as long
as you put your South migrations in the ``south_migrations`` directory and
your Django migrations in the ``migrations`` directory.
More information is available in the
`South 1.0 release notes <http://south.readthedocs.org/en/latest/releasenotes/1.0.html#library-migration-path>`_.