diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt index eb228ef9b75c1..c23bdd1fe9617 100644 --- a/docs/faq/admin.txt +++ b/docs/faq/admin.txt @@ -94,10 +94,3 @@ site is built using semantic HTML and plenty of CSS hooks, so any changes you'd like to make should be possible by editing the stylesheet. We've got a :ref:`guide to the CSS used in the admin ` to get you started. -How do I create users without having to edit password hashes? -------------------------------------------------------------- - -If you'd like to use the admin site to create users, upgrade to the Django -development version, where this problem was fixed on Aug. 4, 2006. - -You can also use the Python API. See :ref:`creating users ` for full info. diff --git a/docs/ref/contrib/syndication.txt b/docs/ref/contrib/syndication.txt index a75f736e6b2b3..e467a9396b896 100644 --- a/docs/ref/contrib/syndication.txt +++ b/docs/ref/contrib/syndication.txt @@ -36,12 +36,6 @@ class and point to it in your :ref:`URLconf `. Initialization -------------- -If you're not using the latest Django development version, you'll need to make -sure Django's sites framework is installed -- including its database table. (See -the :mod:`sites framework documentation ` for more -information.) This has changed in the Django development version; the -syndication feed framework no longer requires the sites framework. - To activate syndication feeds on your Django site, add this line to your :ref:`URLconf `:: @@ -152,8 +146,7 @@ into those elements. * ``{{ site }}`` -- A :class:`django.contrib.sites.models.Site` object representing the current site. This is useful for ``{{ site.domain - }}`` or ``{{ site.name }}``. Note that if you're using the latest - Django development version and do *not* have the Django sites + }}`` or ``{{ site.name }}``. If you do *not* have the Django sites framework installed, this will be set to a :class:`django.contrib.sites.models.RequestSite` object. See the :ref:`RequestSite section of the sites framework documentation diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index 9f25b1015ee42..016ef397b2b64 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -51,13 +51,9 @@ Getting runtime help .. django-admin-option:: --help -In Django 0.96, run ``django-admin.py --help`` to display a help message that -includes a terse list of all available subcommands and options. - -In the Django development version, run ``django-admin.py help`` to display a -list of all available subcommands. Run ``django-admin.py help `` -to display a description of the given subcommand and a list of its available -options. +Run ``django-admin.py help`` to display a list of all available subcommands. +Run ``django-admin.py help `` to display a description of the +given subcommand and a list of its available options. App names --------- @@ -246,13 +242,6 @@ executed. This means that all data will be removed from the database, any post-synchronization handlers will be re-executed, and the ``initial_data`` fixture will be re-installed. -The behavior of this command has changed in the Django development version. -Previously, this command cleared *every* table in the database, including any -table that Django didn't know about (i.e., tables that didn't have associated -models and/or weren't in ``INSTALLED_APPS``). Now, the command only clears -tables that are represented by Django models and are activated in -``INSTALLED_APPS``. - .. django-admin-option:: --noinput Use the ``--noinput`` option to suppress all user prompting, such as "Are diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt index 0656c323aeafc..3e3ec0253eef1 100644 --- a/docs/ref/forms/fields.txt +++ b/docs/ref/forms/fields.txt @@ -316,8 +316,9 @@ For each field, we describe the default widget used if you don't specify * Error message keys: ``required`` .. versionchanged:: 1.0 - The empty value for a ``CheckboxInput`` (and hence the standard ``BooleanField``) - has changed to return ``False`` instead of ``None`` in the development version. + The empty value for a ``CheckboxInput`` (and hence the standard + ``BooleanField``) has changed to return ``False`` instead of ``None`` in + the Django 1.0. .. note:: diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt index ac1e2ffffb4bb..4f2a92a66bc4b 100644 --- a/docs/ref/models/fields.txt +++ b/docs/ref/models/fields.txt @@ -413,11 +413,6 @@ The admin represents this as an ```` (a single-line input). A :class:`CharField` that checks that the value is a valid e-mail address. -In Django 0.96, this doesn't accept :attr:`~CharField.max_length`; its -:class:`~CharField.max_length` is automatically set to 75. In the Django -development version, :class:`~CharField.max_length` is set to 75 by default, but -you can specify it to override default behavior. - ``FileField`` ------------- @@ -577,11 +572,6 @@ A floating-point number represented in Python by a ``float`` instance. The admin represents this as an ```` (a single-line input). -**NOTE:** The semantics of :class:`FloatField` have changed in the Django -development version. See the `Django 0.96 documentation`_ for the old behavior. - -.. _Django 0.96 documentation: http://www.djangoproject.com/documentation/0.96/model-api/#floatfield - ``ImageField`` -------------- diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index c1fbdce5caf74..3525865ac6fec 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -959,10 +959,10 @@ SQL equivalents:: SELECT ... WHERE id IS NULL; .. versionchanged:: 1.0 - The semantics of ``id__exact=None`` have - changed in the development version. Previously, it was (intentionally) - converted to ``WHERE id = NULL`` at the SQL level, which would never match - anything. It has now been changed to behave the same as ``id__isnull=True``. + The semantics of ``id__exact=None`` have changed in Django 1.0. Previously, + it was (intentionally) converted to ``WHERE id = NULL`` at the SQL level, + which would never match anything. It has now been changed to behave the + same as ``id__isnull=True``. .. admonition:: MySQL comparisons diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index e347aab0bf801..7652249514149 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -151,16 +151,19 @@ DATABASE_ENGINE Default: ``''`` (Empty string) -The database backend to use. The build-in database backends are +The database backend to use. The built-in database backends are ``'postgresql_psycopg2'``, ``'postgresql'``, ``'mysql'``, ``'sqlite3'``, and ``'oracle'``. -In the Django development version, you can use a database backend that doesn't -ship with Django by setting ``DATABASE_ENGINE`` to a fully-qualified path (i.e. +You can use a database backend that doesn't ship with Django by setting +``DATABASE_ENGINE`` to a fully-qualified path (i.e. ``mypackage.backends.whatever``). Writing a whole new database backend from scratch is left as an exercise to the reader; see the other backends for examples. +.. versionadded:: 1.0 + Support for external database backends is new in 1.0. + .. setting:: DATABASE_HOST DATABASE_HOST diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt index 45d5b1af08975..3708fbb945a9c 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 ad3fe0249105f..3cbb66068f30e 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 b1a8beeb68704..00df558c2370f 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 8970ab7bae9fc..d99102562f7aa 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`_.