Fixed #9477 -- Removed and edited a bunch of references to "development

version". Some were replaced with versionadded or versionchanged directives.
Other, more minor ones, were removed altogether.

Based on a patch from James Bennett.


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

4 files changed, 13 insertions, 13 deletions

diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt
index 45d5b1af08..3708fbb945 100644
--- a/docs/topics/auth.txt
+++ b/docs/topics/auth.txt
@@ -320,8 +320,10 @@ Hashtype is either ``sha1`` (default), ``md5`` or ``crypt`` -- the algorithm
 used to perform a one-way hash of the password. Salt is a random string used
 to salt the raw password to create the hash. Note that the ``crypt`` method is
 only supported on platforms that have the standard Python ``crypt`` module
-available, and ``crypt`` support is only available in the Django development
-version.
+available.
+
+.. versionadded:: 1.0
+    Support for the ``crypt`` module is new in Django 1.0.
 
 For example::
 
@@ -626,7 +628,6 @@ The login_required decorator
         def my_view(request):
             # ...
 
-    In the Django development version,
     :func:`~django.contrib.auth.decorators.login_required` also takes an
     optional ``redirect_field_name`` parameter. Example::
 
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index ad3fe02491..3cbb66068f 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -77,9 +77,9 @@ the full list of conversions:
     ===============================  ========================================
 
 
-.. note::
+.. versionadded:: 1.0
     The ``FloatField`` form field and ``DecimalField`` model and form fields
-    are new in the development version.
+    are new in Django 1.0.
 
 As you might expect, the ``ForeignKey`` and ``ManyToManyField`` model field
 types are special cases:
diff --git a/docs/topics/i18n.txt b/docs/topics/i18n.txt
index b1a8beeb68..00df558c23 100644
--- a/docs/topics/i18n.txt
+++ b/docs/topics/i18n.txt
@@ -806,8 +806,7 @@ The view expects to be called via the ``POST`` method, with a ``language``
 parameter set in request. If session support is enabled, the view
 saves the language choice in the user's session. Otherwise, it saves the
 language choice in a cookie that is by default named ``django_language``.
-(The name can be changed through the ``LANGUAGE_COOKIE_NAME`` setting if you're
-using the Django development version.)
+(The name can be changed through the ``LANGUAGE_COOKIE_NAME`` setting.)
 
 After setting the language choice, Django redirects the user, following this
 algorithm:
diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt
index 304ed48f3b..23ac2481e7 100644
--- a/docs/topics/testing.txt
+++ b/docs/topics/testing.txt
@@ -186,12 +186,12 @@ test utility is to find all the test cases (that is, subclasses of
 ``unittest.TestCase``) in ``models.py`` and ``tests.py``, automatically build a
 test suite out of those test cases, and run that suite.
 
-In the Django development version, there is a second way to define the test
-suite for a module: if you define a function called ``suite()`` in either
-``models.py`` or ``tests.py``, the Django test runner will use that function
-to construct the test suite for that module. This follows the `suggested
-organization`_ for unit tests. See the Python documentation for more details on
-how to construct a complex test suite.
+There is a second way to define the test suite for a module: if you define a
+function called ``suite()`` in either ``models.py`` or ``tests.py``, the
+Django test runner will use that function to construct the test suite for that
+module. This follows the `suggested organization`_ for unit tests. See the
+Python documentation for more details on how to construct a complex test
+suite.
 
 For more details about ``unittest``, see the `standard library unittest
 documentation`_.