put the sqlite thing near the top as it's the other big feature

diff --git a/docs/build/changelog.rst b/docs/build/changelog.rst
index 9001333c2f482f37935df59a556d43eaaa8880d7..3cc30264795a44384df21e941dcdc91ffffc2b92 100644 (file)
--- a/docs/build/changelog.rst
+++ b/docs/build/changelog.rst
@@ -26,6 +26,36 @@ Changelog
 
           :ref:`branches`
 
+    .. change::
+      :tags: feature, operations, sqlite
+      :tickets: 21
+
+      Added "move and copy" workflow, where a table to be altered is copied to
+      a new one with the new structure and the old one dropped, is now
+      implemented for SQLite as well as all database backends in general
+      using the new :meth:`.Operations.batch_alter_table` system.   This
+      directive provides a table-specific operations context which gathers
+      column- and constraint-level mutations specific to that table, and
+      at the end of the context creates a new table combining the structure
+      of the old one with the given changes, copies data from old table to new,
+      and finally drops the old table,
+      renaming the new one to the existing name.  This is required for
+      fully featured SQLite migrations, as SQLite has very little support for the
+      traditional ALTER directive.   The batch directive
+      is intended to produce code that is still compatible with other databases,
+      in that the "move and copy" process only occurs for SQLite by default,
+      while still providing some level of sanity to SQLite's
+      requirement by allowing multiple table mutation operations to
+      proceed within one "move and copy" as well as providing explicit
+      control over when this operation actually occurs.  The "move and copy"
+      feature may be optionally applied to other backends as well, however
+      dealing with referential integrity constraints from other tables must
+      still be handled explicitly.
+
+      .. seealso::
+
+          :ref:`batch_migrations`
+
     .. change::
       :tags: feature, commands
 
@@ -86,36 +116,6 @@ Changelog
       :class:`~sqlalchemy.schema.Column` object specifies ``index=True``.
       Pull request courtesy David Szotten.
 
-    .. change::
-      :tags: feature, operations, sqlite
-      :tickets: 21
-
-      Added "move and copy" workflow, where a table to be altered is copied to
-      a new one with the new structure and the old one dropped, is now
-      implemented for SQLite as well as all database backends in general
-      using the new :meth:`.Operations.batch_alter_table` system.   This
-      directive provides a table-specific operations context which gathers
-      column- and constraint-level mutations specific to that table, and
-      at the end of the context creates a new table combining the structure
-      of the old one with the given changes, copies data from old table to new,
-      and finally drops the old table,
-      renaming the new one to the existing name.  This is required for
-      fully featured SQLite migrations, as SQLite has very little support for the
-      traditional ALTER directive.   The batch directive
-      is intended to produce code that is still compatible with other databases,
-      in that the "move and copy" process only occurs for SQLite by default,
-      while still providing some level of sanity to SQLite's
-      requirement by allowing multiple table mutation operations to
-      proceed within one "move and copy" as well as providing explicit
-      control over when this operation actually occurs.  The "move and copy"
-      feature may be optionally applied to other backends as well, however
-      dealing with referential integrity constraints from other tables must
-      still be handled explicitly.
-
-      .. seealso::
-
-          :ref:`batch_migrations`
-
     .. change::
       :tags: feature, operations
       :tickets: 205