[1.7.x] Fixed #22444 -- Marked initial SQL/fixture loading as deprecated.

Thanks Karen Tracey for the report.

Backport of a4acb80463 from master

3 files changed, 20 insertions, 7 deletions

diff --git a/docs/howto/initial-data.txt b/docs/howto/initial-data.txt
index d003db6497..d55cd38609 100644
--- a/docs/howto/initial-data.txt
+++ b/docs/howto/initial-data.txt
@@ -77,6 +77,13 @@ again, you'll wipe out any changes you've made.
 Automatically loading initial data fixtures
 -------------------------------------------
 
+.. deprecated:: 1.7
+
+    If an application uses migrations, there is no automatic loading of
+    fixtures. Since migrations will be required for applications in Django 1.9,
+    this behavior is considered deprecated. If you want to load initial data
+    for an app, consider doing it in a migration.
+
 If you create a fixture named ``initial_data.[xml/yaml/json]``, that fixture will
 be loaded every time you run :djadmin:`migrate`. This is extremely convenient,
 but be careful: remember that the data will be refreshed *every time* you run
@@ -103,6 +110,13 @@ directories.
 Providing initial SQL data
 ==========================
 
+.. deprecated:: 1.7
+
+    If an application uses migrations, there is no loading of initial SQL data
+    (including backend-specific SQL data). Since migrations will be required
+    for applications in Django 1.9, this behavior is considered deprecated.
+    If you want to use initial SQL for an app, consider doing it in a migration.
+
 Django provides a hook for passing the database arbitrary SQL that's executed
 just after the CREATE TABLE statements when you run :djadmin:`migrate`. You can
 use this hook to populate default records, or you could also create SQL
diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
index 893f44b3cd..d0bfc90e20 100644
--- a/docs/internals/deprecation.txt
+++ b/docs/internals/deprecation.txt
@@ -40,7 +40,8 @@ details on these changes.
   and all table/schema editing will be moved to be via ``SchemaEditor`` instead.
 
 * The legacy method of syncing apps without migrations will be removed,
-  and migrations will become compulsory for all apps.
+  and migrations will become compulsory for all apps. This includes automatic
+  loading of fixtures and support for initial SQL data.
 
 * All models will need to be defined inside an installed application or
   declare an explicit :attr:`~django.db.models.Options.app_label`.
@@ -48,10 +49,6 @@ details on these changes.
   is loaded. In particular, it won't be possible to import models inside
   the root package of their application.
 
-* If models are organized in a package, Django will no longer look for
-  :ref:`initial SQL data<initial-sql>` in ``myapp/models/sql/``. Move your
-  custom SQL files to ``myapp/sql/``.
-
 * The model and form ``IPAddressField`` will be removed.
 
 * ``AppCommand.handle_app()`` will no longer be supported.
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index 3f9644f7ba..52edbb4a58 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -1307,8 +1307,10 @@ Custom SQL location for models package
 Previously, if models were organized in a package (``myapp/models/``) rather
 than simply ``myapp/models.py``, Django would look for :ref:`initial SQL data
 <initial-sql>` in ``myapp/models/sql/``. This bug has been fixed so that Django
-will search ``myapp/sql/`` as documented. The old location will continue to
-work until Django 1.9.
+will search ``myapp/sql/`` as documented. After this issue was fixed, migrations
+were added which deprecates initial SQL data. Thus, while this change still
+exists, the deprecation is irrelevant as the entire feature will be removed in
+Django 1.9.
 
 Reorganization of ``django.contrib.sites``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~