From 51c8045145b29fed604f716d4d17958aa803b5ea Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Mon, 24 Mar 2014 11:42:56 -0400 Subject: Removed versionadded/changed annotations for 1.6. --- docs/topics/auth/customizing.txt | 25 ++++--------------------- docs/topics/auth/default.txt | 16 ---------------- docs/topics/auth/passwords.txt | 13 ++----------- docs/topics/cache.txt | 5 ----- docs/topics/db/managers.txt | 4 ---- docs/topics/db/sql.txt | 14 -------------- docs/topics/db/transactions.txt | 35 ++++------------------------------- docs/topics/forms/formsets.txt | 14 -------------- docs/topics/forms/index.txt | 11 ++++------- docs/topics/forms/modelforms.txt | 14 ++------------ docs/topics/http/middleware.txt | 4 ++-- docs/topics/http/sessions.txt | 2 -- docs/topics/http/views.txt | 2 -- docs/topics/i18n/translation.txt | 2 -- docs/topics/logging.txt | 2 -- docs/topics/serialization.txt | 5 ----- docs/topics/testing/advanced.txt | 4 ---- docs/topics/testing/overview.txt | 15 --------------- docs/topics/testing/tools.txt | 17 +++-------------- 19 files changed, 21 insertions(+), 183 deletions(-) (limited to 'docs/topics') diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt index 55bd4811fd..cc8b944ada 100644 --- a/docs/topics/auth/customizing.txt +++ b/docs/topics/auth/customizing.txt @@ -70,6 +70,10 @@ The order of :setting:`AUTHENTICATION_BACKENDS` matters, so if the same username and password is valid in multiple backends, Django will stop processing at the first positive match. +If a backend raises a :class:`~django.core.exceptions.PermissionDenied` +exception, authentication will immediately fail. Django won't check the +backends that follow. + .. note:: Once a user has authenticated, Django stores which backend was used to @@ -81,12 +85,6 @@ processing at the first positive match. you need to force users to re-authenticate using different methods. A simple way to do that is simply to execute ``Session.objects.all().delete()``. -.. versionadded:: 1.6 - - If a backend raises a :class:`~django.core.exceptions.PermissionDenied` - exception, authentication will immediately fail. Django won't check the - backends that follow. - Writing an authentication backend --------------------------------- @@ -570,23 +568,12 @@ The following methods are available on any subclass of :meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password()` were used. - .. versionchanged:: 1.6 - - In Django 1.4 and 1.5, a blank string was unintentionally stored - as an unusable password as well. - .. method:: models.AbstractBaseUser.check_password(raw_password) Returns ``True`` if the given raw string is the correct password for the user. (This takes care of the password hashing in making the comparison.) - .. versionchanged:: 1.6 - - In Django 1.4 and 1.5, a blank string was unintentionally - considered to be an unusable password, resulting in this method - returning ``False`` for such a password. - .. method:: models.AbstractBaseUser.set_unusable_password() Marks the user as having no password set. This isn't the same as @@ -909,10 +896,6 @@ models provided by ``auth`` app:: "Run tests for a simple extension of the built-in User." self.assertSomething() -.. versionchanged:: 1.6 - - In Django 1.5, it wasn't necessary to explicitly import the test User models. - A full example -------------- diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt index 15c895f0aa..58633c556d 100644 --- a/docs/topics/auth/default.txt +++ b/docs/topics/auth/default.txt @@ -851,11 +851,6 @@ patterns. error message since this would expose their account's existence but no mail will be sent either. - .. versionchanged:: 1.6 - - Previously, error messages indicated whether a given email was - registered. - **URL name:** ``password_reset`` **Optional arguments:** @@ -936,15 +931,9 @@ patterns. Someone asked for password reset for email {{ email }}. Follow the link below: {{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %} - .. versionchanged:: 1.6 - - Reversing ``password_reset_confirm`` takes a ``uidb64`` argument instead - of ``uidb36``. - The same template context is used for subject template. Subject must be single line plain text string. - .. function:: password_reset_done(request[, template_name, current_app, extra_context]) The page shown after a user has been emailed a link to reset their @@ -976,11 +965,6 @@ patterns. * ``uidb64``: The user's id encoded in base 64. Defaults to ``None``. - .. versionchanged:: 1.6 - - The ``uidb64`` parameter was previously base 36 encoded and named - ``uidb36``. - * ``token``: Token to check that the password is valid. Defaults to ``None``. diff --git a/docs/topics/auth/passwords.txt b/docs/topics/auth/passwords.txt index 6ad93a3a84..7ddbc63b9a 100644 --- a/docs/topics/auth/passwords.txt +++ b/docs/topics/auth/passwords.txt @@ -183,11 +183,8 @@ can switch to new (and better) storage algorithms as they get invented. However, Django can only upgrade passwords that use algorithms mentioned in :setting:`PASSWORD_HASHERS`, so as you upgrade to new systems you should make sure never to *remove* entries from this list. If you do, users using -unmentioned algorithms won't be able to upgrade. - -.. versionadded:: 1.6 - - Passwords will be upgraded when changing the PBKDF2 iteration count. +unmentioned algorithms won't be able to upgrade. Passwords will be upgraded +when changing the PBKDF2 iteration count. .. _sha1: http://en.wikipedia.org/wiki/SHA1 .. _pbkdf2: http://en.wikipedia.org/wiki/PBKDF2 @@ -214,12 +211,6 @@ from the ``User`` model. database to check against, and returns ``True`` if they match, ``False`` otherwise. - .. versionchanged:: 1.6 - - In Django 1.4 and 1.5, a blank string was unintentionally considered - to be an unusable password, resulting in this method returning - ``False`` for such a password. - .. function:: make_password(password[, salt, hashers]) Creates a hashed password in the format used by this application. It takes diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt index 0d8f957d52..f9623b324b 100644 --- a/docs/topics/cache.txt +++ b/docs/topics/cache.txt @@ -771,11 +771,6 @@ of the appropriate backend in the :setting:`CACHES` setting (explained above). It's the number of seconds the value should be stored in the cache. Passing in ``None`` for ``timeout`` will cache the value forever. -.. versionchanged:: 1.6 - - Previously, passing ``None`` explicitly would use the default timeout - value. - If the object doesn't exist in the cache, ``cache.get()`` returns ``None``:: # Wait 30 seconds for 'my_key' to expire... 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 `. - .. _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 `, 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 diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt index 0e32d6131f..44d3154683 100644 --- a/docs/topics/forms/formsets.txt +++ b/docs/topics/forms/formsets.txt @@ -118,13 +118,6 @@ affect validation. If ``validate_max=True`` is passed to the :func:`~django.forms.formsets.formset_factory`, then ``max_num`` will affect validation. See :ref:`validate_max`. -.. versionchanged:: 1.6 - - The ``validate_max`` parameter was added to - :func:`~django.forms.formsets.formset_factory`. Also, the behavior of - ``FormSet`` was brought in line with that of ``ModelFormSet`` so that it - displays initial data regardless of ``max_num``. - Formset validation ------------------ @@ -169,8 +162,6 @@ the expected error message appears for the second item. .. method:: BaseFormSet.total_error_count() -.. versionadded:: 1.6 - To check how many errors there are in the formset, we can use the ``total_error_count`` method:: @@ -344,11 +335,6 @@ excessive. truncated entirely. This is to protect against memory exhaustion attacks using forged POST requests. -.. versionchanged:: 1.6 - - The ``validate_max`` parameter was added to - :func:`~django.forms.formsets.formset_factory`. - ``validate_min`` ~~~~~~~~~~~~~~~~ diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt index 441ab2eea3..9d93083f91 100644 --- a/docs/topics/forms/index.txt +++ b/docs/topics/forms/index.txt @@ -317,14 +317,11 @@ attributes, which can be useful in your templates: The label of the field, e.g. ``Email address``. ``{{ field.label_tag }}`` - The field's label wrapped in the appropriate HTML ``