Removed versionadded/changed annotations for 1.8.

docs/howto/custom-lookups.txt

@@ -52,10 +52,6 @@ Lookup registration can also be done using a decorator pattern::
     class NotEqualLookup(Lookup):
         # ...
 
-.. versionchanged:: 1.8
-
-    The ability to use the decorator pattern was added.
-
 We can now use ``foo__ne`` for any field ``foo``. You will need to ensure that
 this registration happens before you try to create any querysets using it. You
 could place the implementation in a ``models.py`` file, or register the lookup

docs/howto/custom-management-commands.txt

@@ -136,11 +136,6 @@ because some commands shipped with Django perform several tasks (for example,
 user-facing content rendering and database population) that require a
 project-neutral string language.
 
-.. versionchanged:: 1.8
-
-    In previous versions, Django forced the "en-us" locale instead of
-    deactivating translations.
-
 If, for some reason, your custom management command needs to use a fixed locale,
 you should manually activate and deactivate it in your
 :meth:`~BaseCommand.handle` method using the functions provided by the I18N
@@ -226,8 +221,6 @@ All attributes can be set in your derived class and can be used in
 
 .. attribute:: BaseCommand.missing_args_message
 
-    .. versionadded:: 1.8
-
     If your command defines mandatory positional arguments, you can customize
     the message error returned in the case of missing arguments. The default is
     output by :py:mod:`argparse` ("too few arguments").
@@ -281,8 +274,6 @@ the :meth:`~BaseCommand.handle` method must be implemented.
 
 .. method:: BaseCommand.add_arguments(parser)
 
-    .. versionadded:: 1.8
-
     Entry point to add parser arguments to handle command line arguments passed
     to the command. Custom commands should override this method to add both
     positional and optional arguments accepted by the command. Calling

docs/howto/custom-template-tags.txt

@@ -340,8 +340,6 @@ Template filter code falls into one of two situations:
 
 .. warning:: Avoiding XSS vulnerabilities when reusing built-in filters
 
-    .. versionchanged:: 1.8
-
     Django's built-in filters have ``autoescape=True`` by default in order to
     get the proper autoescaping behavior and avoid a cross-site script
     vulnerability.
@@ -849,15 +847,6 @@ template yourself. For example::
         t = context.template.engine.get_template('small_fragment.html')
         return t.render(Context({'var': obj}, autoescape=context.autoescape))
 
-.. versionchanged:: 1.8
-
-    The ``template`` attribute of ``Context`` objects was added in Django 1.8.
-    :meth:`context.template.engine.get_template
-    <django.template.Engine.get_template>` must be used instead of
-    :func:`django.template.loader.get_template` because the latter now returns
-    a wrapper whose ``render`` method doesn't accept a
-    :class:`~django.template.Context`.
-
 If we had neglected to pass in the current ``context.autoescape`` value to our
 new ``Context`` in this example, the results would have *always* been
 automatically escaped, which may not be the desired behavior if the template

docs/howto/writing-migrations.txt

@@ -36,8 +36,6 @@ attribute::
             migrations.RunPython(forwards),
         ]
 
-.. versionadded:: 1.8
-
 You can also provide hints that will be passed to the :meth:`allow_migrate()`
 method of database routers as ``**hints``: