Updated some docs for the delayed deprecation of legacy table creation; refs #22340.

docs/howto/initial-data.txt

@@ -80,7 +80,7 @@ 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,
+    fixtures. Since migrations will be required for applications in Django 2.0,
     this behavior is considered deprecated. If you want to load initial data
     for an app, consider doing it in a migration.
 
@@ -114,7 +114,7 @@ Providing initial SQL data
 
     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.
+    for applications in Django 2.0, 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

docs/internals/deprecation.txt

@@ -62,6 +62,10 @@ 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.

docs/releases/1.7.txt

@@ -1312,10 +1312,11 @@ 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. After this issue was fixed, migrations
+will search ``myapp/sql/`` as documented. The old location will continue to
-were added which deprecates initial SQL data. Thus, while this change still
+work until Django 1.9. After this issue was fixed, migrations were added which
-exists, the deprecation is irrelevant as the entire feature will be removed in
+deprecates initial SQL data. Thus, while this change still exists, the
-Django 1.9.
+deprecation is somehwhat irrelevant as the entire feature will be removed in
+Django 2.0 when migrations become compulsory for all applications.
 
 Reorganization of ``django.contrib.sites``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~