Django

Code

Changeset 9454

Show
Ignore:
Timestamp:
11/14/08 23:51:25 (2 months ago)
Author:
mtredinnick
Message:

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.

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • django/trunk/docs/faq/admin.txt

    r9330 r9454  
    9595:ref:`guide to the CSS used in the admin <obsolete-admin-css>` to get you started. 
    9696 
    97 How do I create users without having to edit password hashes? 
    98 ------------------------------------------------------------- 
    99  
    100 If you'd like to use the admin site to create users, upgrade to the Django 
    101 development version, where this problem was fixed on Aug. 4, 2006. 
    102  
    103 You can also use the Python API. See :ref:`creating users <topics-auth-creating-users>` for full info. 
  • django/trunk/docs/ref/contrib/syndication.txt

    r9373 r9454  
    3636Initialization 
    3737-------------- 
    38  
    39 If you're not using the latest Django development version, you'll need to make 
    40 sure Django's sites framework is installed -- including its database table. (See 
    41 the :mod:`sites framework documentation <django.contrib.sites>` for more 
    42 information.) This has changed in the Django development version; the 
    43 syndication feed framework no longer requires the sites framework. 
    4438 
    4539To activate syndication feeds on your Django site, add this line to your 
     
    153147         * ``{{ site }}`` -- A :class:`django.contrib.sites.models.Site` object 
    154148           representing the current site. This is useful for ``{{ site.domain 
    155            }}`` or ``{{ site.name }}``. Note that if you're using the latest 
    156            Django development version and do *not* have the Django sites 
     149           }}`` or ``{{ site.name }}``. If you do *not* have the Django sites 
    157150           framework installed, this will be set to a 
    158151           :class:`django.contrib.sites.models.RequestSite` object. See the 
  • django/trunk/docs/ref/django-admin.txt

    r9110 r9454  
    5252.. django-admin-option:: --help 
    5353 
    54 In Django 0.96, run ``django-admin.py --help`` to display a help message that 
    55 includes a terse list of all available subcommands and options. 
    56  
    57 In the Django development version, run ``django-admin.py help`` to display a 
    58 list of all available subcommands. Run ``django-admin.py help <subcommand>`` 
    59 to display a description of the given subcommand and a list of its available 
    60 options. 
     54Run ``django-admin.py help`` to display a list of all available subcommands. 
     55Run ``django-admin.py help <subcommand>`` to display a description of the 
     56given subcommand and a list of its available options. 
    6157 
    6258App names 
     
    242238post-synchronization handlers will be re-executed, and the ``initial_data`` 
    243239fixture will be re-installed. 
    244  
    245 The behavior of this command has changed in the Django development version. 
    246 Previously, this command cleared *every* table in the database, including any 
    247 table that Django didn't know about (i.e., tables that didn't have associated 
    248 models and/or weren't in ``INSTALLED_APPS``). Now, the command only clears 
    249 tables that are represented by Django models and are activated in 
    250 ``INSTALLED_APPS``. 
    251240 
    252241.. django-admin-option:: --noinput 
  • django/trunk/docs/ref/forms/fields.txt

    r8843 r9454  
    317317 
    318318.. versionchanged:: 1.0 
    319    The empty value for a ``CheckboxInput`` (and hence the standard ``BooleanField``) 
    320    has changed to return ``False`` instead of ``None`` in the development version. 
     319   The empty value for a ``CheckboxInput`` (and hence the standard 
     320   ``BooleanField``) has changed to return ``False`` instead of ``None`` in 
     321   the Django 1.0. 
    321322 
    322323.. note:: 
  • django/trunk/docs/ref/models/fields.txt

    r9083 r9454  
    414414A :class:`CharField` that checks that the value is a valid e-mail address. 
    415415 
    416 In Django 0.96, this doesn't accept :attr:`~CharField.max_length`; its 
    417 :class:`~CharField.max_length` is automatically set to 75. In the Django 
    418 development version, :class:`~CharField.max_length` is set to 75 by default, but 
    419 you can specify it to override default behavior. 
    420  
    421416``FileField`` 
    422417------------- 
     
    578573The admin represents this as an ``<input type="text">`` (a single-line input). 
    579574 
    580 **NOTE:** The semantics of :class:`FloatField` have changed in the Django 
    581 development version. See the `Django 0.96 documentation`_ for the old behavior. 
    582  
    583 .. _Django 0.96 documentation: http://www.djangoproject.com/documentation/0.96/model-api/#floatfield 
    584  
    585575``ImageField`` 
    586576-------------- 
  • django/trunk/docs/ref/models/querysets.txt

    r9330 r9454  
    960960 
    961961.. versionchanged:: 1.0 
    962    The semantics of ``id__exact=None`` have 
    963    changed in the development version. Previously, it was (intentionally) 
    964    converted to ``WHERE id = NULL`` at the SQL level, which would never match 
    965    anything. It has now been changed to behave the same as ``id__isnull=True``. 
     962   The semantics of ``id__exact=None`` have changed in Django 1.0. Previously, 
     963   it was (intentionally) converted to ``WHERE id = NULL`` at the SQL level, 
     964   which would never match anything. It has now been changed to behave the 
     965   same as ``id__isnull=True``. 
    966966 
    967967.. admonition:: MySQL comparisons 
  • django/trunk/docs/ref/settings.txt

    r9175 r9454  
    152152Default: ``''`` (Empty string) 
    153153 
    154 The database backend to use. The build-in database backends are 
     154The database backend to use. The built-in database backends are 
    155155``'postgresql_psycopg2'``, ``'postgresql'``, ``'mysql'``, ``'sqlite3'``, and 
    156156``'oracle'``. 
    157157 
    158 In the Django development version, you can use a database backend that doesn't 
    159 ship with Django by setting ``DATABASE_ENGINE`` to a fully-qualified path (i.e. 
     158You can use a database backend that doesn't ship with Django by setting 
     159``DATABASE_ENGINE`` to a fully-qualified path (i.e. 
    160160``mypackage.backends.whatever``). Writing a whole new database backend from 
    161161scratch is left as an exercise to the reader; see the other backends for 
    162162examples. 
     163 
     164.. versionadded:: 1.0 
     165    Support for external database backends is new in 1.0. 
    163166 
    164167.. setting:: DATABASE_HOST 
  • django/trunk/docs/topics/auth.txt

    r9330 r9454  
    321321to salt the raw password to create the hash. Note that the ``crypt`` method is 
    322322only supported on platforms that have the standard Python ``crypt`` module 
    323 available, and ``crypt`` support is only available in the Django development 
    324 version. 
     323available. 
     324 
     325.. versionadded:: 1.0 
     326    Support for the ``crypt`` module is new in Django 1.0. 
    325327 
    326328For example:: 
     
    627629            # ... 
    628630 
    629     In the Django development version, 
    630631    :func:`~django.contrib.auth.decorators.login_required` also takes an 
    631632    optional ``redirect_field_name`` parameter. Example:: 
  • django/trunk/docs/topics/forms/modelforms.txt

    r9023 r9454  
    7878 
    7979 
    80 .. note:: 
     80.. versionadded:: 1.0 
    8181    The ``FloatField`` form field and ``DecimalField`` model and form fields 
    82     are new in the development version
     82    are new in Django 1.0
    8383 
    8484As you might expect, the ``ForeignKey`` and ``ManyToManyField`` model field 
  • django/trunk/docs/topics/i18n.txt

    r9330 r9454  
    807807saves the language choice in the user's session. Otherwise, it saves the 
    808808language choice in a cookie that is by default named ``django_language``. 
    809 (The name can be changed through the ``LANGUAGE_COOKIE_NAME`` setting if you're 
    810 using the Django development version.) 
     809(The name can be changed through the ``LANGUAGE_COOKIE_NAME`` setting.) 
    811810 
    812811After setting the language choice, Django redirects the user, following this 
  • django/trunk/docs/topics/testing.txt

    r9429 r9454  
    187187test suite out of those test cases, and run that suite. 
    188188 
    189 In the Django development version, there is a second way to define the test 
    190 suite for a module: if you define a function called ``suite()`` in either 
    191 ``models.py`` or ``tests.py``, the Django test runner will use that function 
    192 to construct the test suite for that module. This follows the `suggested 
    193 organization`_ for unit tests. See the Python documentation for more details on 
    194 how to construct a complex test suite. 
     189There is a second way to define the test suite for a module: if you define a 
     190function called ``suite()`` in either ``models.py`` or ``tests.py``, the 
     191Django test runner will use that function to construct the test suite for that 
     192module. This follows the `suggested organization`_ for unit tests. See the 
     193Python documentation for more details on how to construct a complex test 
     194suite. 
    195195 
    196196For more details about ``unittest``, see the `standard library unittest