From c79faae761659d51d58782dbd2b8058fb4668cfa Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Mon, 26 Jan 2015 15:39:52 -0500 Subject: Removed versionadded/changed notes for 1.7. --- docs/howto/custom-file-storage.txt | 8 -------- docs/howto/custom-lookups.txt | 2 -- docs/howto/custom-management-commands.txt | 2 -- docs/howto/custom-model-fields.txt | 13 ++----------- docs/howto/static-files/index.txt | 6 ------ docs/howto/windows.txt | 5 ----- 6 files changed, 2 insertions(+), 34 deletions(-) (limited to 'docs/howto') diff --git a/docs/howto/custom-file-storage.txt b/docs/howto/custom-file-storage.txt index 3d2c96e2bd..a6c8745462 100644 --- a/docs/howto/custom-file-storage.txt +++ b/docs/howto/custom-file-storage.txt @@ -109,14 +109,6 @@ free unique filename cannot be found, a :exc:`SuspiciousFileOperation If a file with ``name`` already exists, an underscore plus a random 7 character alphanumeric string is appended to the filename before the extension. -.. versionchanged:: 1.7 - - Previously, an underscore followed by a number (e.g. ``"_1"``, ``"_2"``, - etc.) was appended to the filename until an available name in the destination - directory was found. A malicious user could exploit this deterministic - algorithm to create a denial-of-service attack. This change was also made - in Django 1.6.6, 1.5.9, and 1.4.14. - .. versionchanged:: 1.8 The ``max_length`` argument was added. diff --git a/docs/howto/custom-lookups.txt b/docs/howto/custom-lookups.txt index 6b9545a568..58b0215019 100644 --- a/docs/howto/custom-lookups.txt +++ b/docs/howto/custom-lookups.txt @@ -2,8 +2,6 @@ Custom Lookups ============== -.. versionadded:: 1.7 - .. currentmodule:: django.db.models Django offers a wide variety of :ref:`built-in lookups ` for diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt index b3451732bb..d5dd800a94 100644 --- a/docs/howto/custom-management-commands.txt +++ b/docs/howto/custom-management-commands.txt @@ -351,8 +351,6 @@ the :meth:`~BaseCommand.handle` method must be implemented. .. method:: BaseCommand.check(app_configs=None, tags=None, display_num_errors=False) - .. versionadded:: 1.7 - Uses the system check framework to inspect the entire Django project for potential problems. Serious problems are raised as a :class:`CommandError`; warnings are output to stderr; minor notifications are output to stdout. diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt index f35cc41d3d..5c41d92bb6 100644 --- a/docs/howto/custom-model-fields.txt +++ b/docs/howto/custom-model-fields.txt @@ -230,12 +230,6 @@ meaning they do for normal Django fields. See the :doc:`field documentation Field deconstruction -------------------- -.. versionadded:: 1.7 - - ``deconstruct()`` is part of the migrations framework in Django 1.7 and - above. If you have custom fields from previous versions they will - need this method added before you can use them with migrations. - The counterpoint to writing your ``__init__()`` method is writing the ``deconstruct()`` method. This method tells Django how to take an instance of your new field and reduce it to a serialized form - in particular, what @@ -590,11 +584,8 @@ valid Django filter lookups: ``exact``, ``iexact``, ``contains``, ``icontains``, ``endswith``, ``iendswith``, ``range``, ``year``, ``month``, ``day``, ``isnull``, ``search``, ``regex``, and ``iregex``. -.. versionadded:: 1.7 - - If you are using :doc:`Custom lookups ` the - ``lookup_type`` can be any ``lookup_name`` used by the project's custom - lookups. +If you are using :doc:`custom lookups `, the +``lookup_type`` can be any ``lookup_name`` used by the project's custom lookups. Your method must be prepared to handle all of these ``lookup_type`` values and should raise either a ``ValueError`` if the ``value`` is of the wrong sort (a diff --git a/docs/howto/static-files/index.txt b/docs/howto/static-files/index.txt index d05ae6afc5..f9fd390ef0 100644 --- a/docs/howto/static-files/index.txt +++ b/docs/howto/static-files/index.txt @@ -158,12 +158,6 @@ during execution of these tests in a way very similar to what we get at development time with ``DEBUG = True``, i.e. without having to collect them using :djadmin:`collectstatic` first. -.. versionadded:: 1.7 - - :class:`django.contrib.staticfiles.testing.StaticLiveServerTestCase` is new - in Django 1.7. Previously its functionality was provided by - :class:`django.test.LiveServerTestCase`. - Deployment ========== diff --git a/docs/howto/windows.txt b/docs/howto/windows.txt index 98da7fa31b..2e92ace34e 100644 --- a/docs/howto/windows.txt +++ b/docs/howto/windows.txt @@ -62,11 +62,6 @@ This will download and install Django. After the installation has completed, you can verify your Django installation by executing ``django-admin --version`` in the command prompt. -.. versionchanged:: 1.7 - - In Django 1.7, a ``.exe`` has been introduced, so just use - ``django-admin`` in place of ``django-admin.py`` in the command prompt. - See :ref:`database-installation` for information on database installation with Django. -- cgit v1.3