Removed versionadded/changed annotations for 1.6.

3 files changed, 4 insertions, 49 deletions

diff --git a/docs/topics/db/managers.txt b/docs/topics/db/managers.txt
index ba9b76c880..705d721c8d 100644
--- a/docs/topics/db/managers.txt
+++ b/docs/topics/db/managers.txt
@@ -179,10 +179,6 @@ your choice of default manager in order to avoid a situation where overriding
 ``get_queryset()`` results in an inability to retrieve objects you'd like to
 work with.
 
-.. versionchanged:: 1.6
-
-    The ``get_queryset`` method was previously named ``get_query_set``.
-
 .. _managers-for-related-objects:
 
 Using managers for related object access
diff --git a/docs/topics/db/sql.txt b/docs/topics/db/sql.txt
index 9dcc98a3cb..2b2b4261f6 100644
--- a/docs/topics/db/sql.txt
+++ b/docs/topics/db/sql.txt
@@ -197,13 +197,6 @@ argument.
 
 __ http://en.wikipedia.org/wiki/SQL_injection
 
-.. versionchanged:: 1.6
-
-    In Django 1.5 and earlier, you could pass parameters as dictionaries
-    when using PostgreSQL or MySQL, although this wasn't documented. Now
-    you can also do this when using Oracle, and it is officially supported.
-
-
 .. _executing-custom-sql:
 
 Executing custom SQL directly
@@ -236,13 +229,6 @@ For example::
 
         return row
 
-.. versionchanged:: 1.6
-
-    In Django 1.5 and earlier, after performing a data changing operation, you
-    had to call ``transaction.commit_unless_managed()`` to ensure your changes
-    were committed to the database. Since Django now defaults to database-level
-    autocommit, this isn't necessary any longer.
-
 Note that if you want to include literal percent signs in the query, you have to
 double them in the case you are passing parameters::
 
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index 9e1c86276f..c4ffa4b35e 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -24,11 +24,6 @@ integrity of ORM operations that require multiple queries, especially
 Django's :class:`~django.test.TestCase` class also wraps each test in a
 transaction for performance reasons.
 
-.. versionchanged:: 1.6
-
-    Previous version of Django featured :ref:`a more complicated default
-    behavior <transactions-upgrading-from-1.5>`.
-
 .. _tying-transactions-to-http-requests:
 
 Tying transactions to HTTP requests
@@ -93,16 +88,9 @@ still possible to prevent views from running in a transaction.
 
     It only works if it's applied to the view itself.
 
-.. versionchanged:: 1.6
-
-    Django used to provide this feature via ``TransactionMiddleware``, which is
-    now deprecated.
-
 Controlling transactions explicitly
 -----------------------------------
 
-.. versionadded:: 1.6
-
 Django provides a single API to control database transactions.
 
 .. function:: atomic(using=None, savepoint=True)
@@ -251,11 +239,6 @@ on.
 To avoid this, you can :ref:`deactivate the transaction management
 <deactivate-transaction-management>`, but it isn't recommended.
 
-.. versionchanged:: 1.6
-
-    Before Django 1.6, autocommit was turned off, and it was emulated by
-    forcing a commit after write operations in the ORM.
-
 .. _deactivate-transaction-management:
 
 Deactivating transaction management
@@ -272,10 +255,6 @@ by Django or by third-party libraries. Thus, this is best used in situations
 where you want to run your own transaction-controlling middleware or do
 something really strange.
 
-.. versionchanged:: 1.6
-
-    This used to be controlled by the ``TRANSACTIONS_MANAGED`` setting.
-
 Low-level APIs
 ==============
 
@@ -292,8 +271,6 @@ Low-level APIs
 Autocommit
 ----------
 
-.. versionadded:: 1.6
-
 Django provides a straightforward API in the :mod:`django.db.transaction`
 module to manage the autocommit state of each database connection.
 
@@ -360,12 +337,10 @@ you issue a rollback, the entire transaction is rolled back. Savepoints
 provide the ability to perform a fine-grained rollback, rather than the full
 rollback that would be performed by ``transaction.rollback()``.
 
-.. versionchanged:: 1.6
-
-    When the :func:`atomic` decorator is nested, it creates a savepoint to allow
-    partial commit or rollback. You're strongly encouraged to use :func:`atomic`
-    rather than the functions described below, but they're still part of the
-    public API, and there's no plan to deprecate them.
+When the :func:`atomic` decorator is nested, it creates a savepoint to allow
+partial commit or rollback. You're strongly encouraged to use :func:`atomic`
+rather than the functions described below, but they're still part of the
+public API, and there's no plan to deprecate them.
 
 Each of these functions takes a ``using`` argument which should be the name of
 a database for which the behavior applies.  If no ``using`` argument is
@@ -419,8 +394,6 @@ The following example demonstrates the use of savepoints::
             transaction.savepoint_rollback(sid)
             # open transaction now contains only a.save()
 
-.. versionadded:: 1.6
-
 Savepoints may be used to recover from a database error by performing a partial
 rollback. If you're doing this inside an :func:`atomic` block, the entire block
 will still be rolled back, because it doesn't know you've handled the situation