Fixed #14000 - remove versionadded/changed tags for Django 1.0 and 1.1

git-svn-id: http://code.djangoproject.com/svn/django/trunk@15055 bcc190cf-cafb-0310-a4f2-bffc1f526a37

4 files changed, 0 insertions, 49 deletions

diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
index a06a1ca2ef..377dcacb8d 100644
--- a/docs/topics/http/file-uploads.txt
+++ b/docs/topics/http/file-uploads.txt
@@ -4,8 +4,6 @@ File Uploads
 
 .. currentmodule:: django.core.files
 
-.. versionadded:: 1.0
-
 When Django handles a file upload, the file data ends up placed in
 :attr:`request.FILES <django.http.HttpRequest.FILES>` (for more on the
 ``request`` object see the documentation for :doc:`request and response objects
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index a569c44825..af27d54257 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -29,8 +29,6 @@ from your ``INSTALLED_APPS``. It'll save you a small bit of overhead.
 Configuring the session engine
 ==============================
 
-.. versionadded:: 1.0
-
 By default, Django stores sessions in your database (using the model
 ``django.contrib.sessions.models.Session``). Though this is convenient, in
 some setups it's faster to store session data elsewhere, so Django can be
@@ -50,9 +48,6 @@ Using cached sessions
 
 For better performance, you may want to use a cache-based session backend.
 
-.. versionchanged:: 1.1
-   Django 1.0 did not include the ``cached_db`` session backend.
-
 To store session data using Django's cache system, you'll first need to make
 sure you've configured your cache; see the :doc:`cache documentation
 </topics/cache>` for details.
@@ -138,15 +133,10 @@ A session object has the following standard dictionary methods:
 
     * ``clear()``
 
-.. versionadded:: 1.0
-   ``setdefault()`` and ``clear()`` are new in this version.
-
 It also has these methods:
 
     * ``flush()``
 
-      .. versionadded:: 1.0
-
       Delete the current session data from the session and regenerate the
       session key value that is sent back to the user in the cookie. This is
       used if you want to ensure that the previous session data can't be
@@ -173,8 +163,6 @@ It also has these methods:
 
     * ``set_expiry(value)``
 
-      .. versionadded:: 1.0
-
       Sets the expiration time for the session. You can pass a number of
       different values:
 
@@ -198,24 +186,18 @@ It also has these methods:
 
     * ``get_expiry_age()``
 
-      .. versionadded:: 1.0
-
       Returns the number of seconds until this session expires. For sessions
       with no custom expiration (or those set to expire at browser close), this
       will equal ``settings.SESSION_COOKIE_AGE``.
 
     * ``get_expiry_date()``
 
-      .. versionadded:: 1.0
-
       Returns the date this session will expire. For sessions with no custom
       expiration (or those set to expire at browser close), this will equal the
       date ``settings.SESSION_COOKIE_AGE`` seconds from now.
 
     * ``get_expire_at_browser_close()``
 
-      .. versionadded:: 1.0
-
       Returns either ``True`` or ``False``, depending on whether the user's
       session cookie will expire when the user's Web browser is closed.
 
@@ -302,8 +284,6 @@ Here's a typical usage example::
 Using sessions out of views
 ===========================
 
-.. versionadded:: 1.0
-
 An API is available to manipulate session data outside of a view::
 
     >>> from django.contrib.sessions.backends.db import SessionStore
@@ -393,8 +373,6 @@ browser-length cookies -- cookies that expire as soon as the user closes his or
 her browser. Use this if you want people to have to log in every time they open
 a browser.
 
-.. versionadded:: 1.0
-
 This setting is a global default and can be overwritten at a per-session level
 by explicitly calling ``request.session.set_expiry()`` as described above in
 `using sessions in views`_.
@@ -424,11 +402,6 @@ A few :doc:`Django settings </ref/settings>` give you control over session behav
 SESSION_ENGINE
 --------------
 
-.. versionadded:: 1.0
-
-.. versionchanged:: 1.1
-   The ``cached_db`` backend was added
-
 Default: ``django.contrib.sessions.backends.db``
 
 Controls where Django stores session data. Valid values are:
@@ -443,8 +416,6 @@ See `configuring the session engine`_ for more details.
 SESSION_FILE_PATH
 -----------------
 
-.. versionadded:: 1.0
-
 Default: ``/tmp/``
 
 If you're using file-based session storage, this sets the directory in
@@ -493,8 +464,6 @@ The name of the cookie to use for sessions. This can be whatever you want.
 SESSION_COOKIE_PATH
 -------------------
 
-.. versionadded:: 1.0
-
 Default: ``'/'``
 
 The path set on the session cookie. This should either match the URL path of
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index ebe72324cb..1c1dc9ef0b 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -152,8 +152,6 @@ This example is equivalent to::
 
 .. function:: redirect(to[, permanent=False], *args, **kwargs)
 
-   .. versionadded:: 1.1
-
    Returns an :class:`~django.http.HttpResponseRedirect` to the appropriate URL
    for the arguments passed.
 
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index d129f424a1..cb37488780 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -225,8 +225,6 @@ The remaining arguments should be tuples in this format::
 url
 ---
 
-.. versionadded:: 1.0
-
 .. function:: url(regex, view, kwargs=None, name=None, prefix='')
 
 You can use the ``url()`` function, instead of a tuple, as an argument to
@@ -285,8 +283,6 @@ include
 A function that takes a full Python import path to another URLconf module that
 should be "included" in this place.
 
-.. versionadded:: 1.1
-
 :func:`include` also accepts as an argument an iterable that returns URL
 patterns.
 
@@ -417,8 +413,6 @@ Django encounters ``include()``, it chops off whatever part of the URL matched
 up to that point and sends the remaining string to the included URLconf for
 further processing.
 
-.. versionadded:: 1.1
-
 Another possibility is to include additional URL patterns not by specifying the
 URLconf Python module defining them as the `include`_ argument but by using
 directly the pattern list as returned by `patterns`_ instead. For example::
@@ -637,8 +631,6 @@ the view prefix (as explained in "The view prefix" above) will have no effect.
 Naming URL patterns
 ===================
 
-.. versionadded:: 1.0
-
 It's fairly common to use the same view function in multiple URL patterns in
 your URLconf. For example, these two URL patterns both point to the ``archive``
 view::
@@ -697,8 +689,6 @@ not restricted to valid Python names.
 URL namespaces
 --------------
 
-.. versionadded:: 1.1
-
 Namespaced URLs are specified using the ``:`` operator. For example, the main
 index page of the admin application is referenced using ``admin:index``. This
 indicates a namespace of ``admin``, and a named URL of ``index``.
@@ -804,8 +794,6 @@ vertical bar (``"|"``) character. You can quite happily use such patterns for
 matching against incoming URLs and sending them off to views, but you cannot
 reverse such patterns.
 
-.. versionadded:: 1.1
-
 The ``current_app`` argument allows you to provide a hint to the resolver
 indicating the application to which the currently executing view belongs.
 This ``current_app`` argument is used as a hint to resolve application
@@ -935,8 +923,6 @@ get_script_prefix()
 
 .. function:: get_script_prefix()
 
-.. versionadded:: 1.0
-
 Normally, you should always use :func:`~django.core.urlresolvers.reverse` or
 :func:`~django.db.models.permalink` to define URLs within your application.
 However, if your application constructs part of the URL hierarchy itself, you