<commit_before>===============================
Django 1.0 beta 1 release notes
===============================


Welcome to Django 1.0 alpha 2!

This is the third in a series of preview/development releases leading
up to the eventual release of Django 1.0, currently scheduled to take
place in early September 2008. This releases is primarily targeted at
developers who are interested in testing the Django codebase and
helping to identify and resolve bugs prior to the final 1.0 release.

As such, this release is *not* intended for production use, and any
such use is discouraged.


What's new in Django 1.0 beta 1
===============================

Django's development trunk has been the site of nearly constant
activity over the past year, with several major new features landing
since the 0.96 release. For features which were new as of Django 1.0
alpha 1, see `the 1.0 alpha 1 release notes`_. For features which were
new as of Django 1.0 alpha 2, see `the 1.0 alpha 2 release notes`_.

This beta release does not contain any major new features, but does
include several smaller updates and improvements to Django:

Generic relations in forms and admin
    Classes are now included in ``django.contrib.contenttypes`` which
    can be used to support generic relations in both the admin
    interface and in end-user forms. See `the documentation for
    generic relations`_ for details.

Improved flexibility in the admin
    Following up on the refactoring of Django's administrative
    interface (``django.contrib.admin``), introduced in Django 1.0
    alpha 1, two new hooks have been added to allow customized pre-
    and post-save handling of model instances in the admin. Full
    details are in `the admin documentation`_.

``INSERT``/``UPDATE`` distinction
    Although Django's default behavior of having a model's ``save()``
    method automatically determine whether to perform an ``INSERT`` or
    an ``UPDATE`` at the SQL level is suitable for the majority of
    cases, there are occasional situations where forcing one or the
    other is useful. As a result, models can now support an additional
    parameter to ``save()`` which can force a specific
    operation. Consult `the database API documentation`_ for details
    and important notes about appropriate use of this parameter.

Split ``CacheMiddleware``
   Django's ``CacheMiddleware`` has been split into three classes:
   ``CacheMiddleware`` itself still exists and retains all of its
   previous functionality, but it is now built from two separate
   middleware classes which handle the two parts of caching (inserting
   into and reading from the cache) separately, offering additional
   flexibility for situations where combining these functions into a
   single middleware posed problems. Full details, including updated
   notes on appropriate use, are in `the caching documentation`_.

Removal of deprecated features
    A number of features and methods which had previously been marked
    as deprecated, and which were scheduled for removal prior to the
    1.0 release, are no longer present in Django. These include
    imports of the form library from ``django.newforms`` (now located
    simply at ``django.forms``), the ``form_for_model`` and
    ``form_for_instance`` helper functions (which have been replaced
    by ``ModelForm``) and a number of deprecated features which were
    replaced by the dispatcher, file-uploading and file-storage
    refactorings introduced in the Django 1.0 alpha releases. A full
    list of these and all other backwards-incompatible changes is
    available on `the Django wiki`_.

A number of other improvements and bugfixes have also been included:
some tricky cases involving case-sensitivity in differing MySQL
collations have been resolved, Windows packaging and installation has
been improved and the method by which Django generates unique session
identifiers has been made much more robust.

.. _the 1.0 alpha 1 release notes: ../release_notes_1.0_alpha/
.. _the 1.0 alpha 1 release notes: ../release_notes_1.0_alpha_2/
.. _the documentation for generic relations: ../contenttypes/#generic-relations
.. _the admin documentation: ../admin/#modeladmin-methods
.. _the database API documentation: ../db-api/#forcing-an-insert-or-update
.. _the caching documentation: ../cache/#the-per-site-cache
.. _the Django wiki: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Removedseveralmoredeprecatedfeaturesfor1.0


The Django 1.0 roadmap
======================

One of the primary goals of this beta release is to focus attention on
the remaining features to be implemented for Django 1.0, and on the<commit_msg>reST fix in release notes<commit_after>===============================
Django 1.0 beta 1 release notes
===============================


Welcome to Django 1.0 alpha 2!

This is the third in a series of preview/development releases leading
up to the eventual release of Django 1.0, currently scheduled to take
place in early September 2008. This releases is primarily targeted at
developers who are interested in testing the Django codebase and
helping to identify and resolve bugs prior to the final 1.0 release.

As such, this release is *not* intended for production use, and any
such use is discouraged.


What's new in Django 1.0 beta 1
===============================

Django's development trunk has been the site of nearly constant
activity over the past year, with several major new features landing
since the 0.96 release. For features which were new as of Django 1.0
alpha 1, see `the 1.0 alpha 1 release notes`_. For features which were
new as of Django 1.0 alpha 2, see `the 1.0 alpha 2 release notes`_.

This beta release does not contain any major new features, but does
include several smaller updates and improvements to Django:

Generic relations in forms and admin
    Classes are now included in ``django.contrib.contenttypes`` which
    can be used to support generic relations in both the admin
    interface and in end-user forms. See `the documentation for
    generic relations`_ for details.

Improved flexibility in the admin
    Following up on the refactoring of Django's administrative
    interface (``django.contrib.admin``), introduced in Django 1.0
    alpha 1, two new hooks have been added to allow customized pre-
    and post-save handling of model instances in the admin. Full
    details are in `the admin documentation`_.

``INSERT``/``UPDATE`` distinction
    Although Django's default behavior of having a model's ``save()``
    method automatically determine whether to perform an ``INSERT`` or
    an ``UPDATE`` at the SQL level is suitable for the majority of
    cases, there are occasional situations where forcing one or the
    other is useful. As a result, models can now support an additional
    parameter to ``save()`` which can force a specific
    operation. Consult `the database API documentation`_ for details
    and important notes about appropriate use of this parameter.

Split ``CacheMiddleware``
   Django's ``CacheMiddleware`` has been split into three classes:
   ``CacheMiddleware`` itself still exists and retains all of its
   previous functionality, but it is now built from two separate
   middleware classes which handle the two parts of caching (inserting
   into and reading from the cache) separately, offering additional
   flexibility for situations where combining these functions into a
   single middleware posed problems. Full details, including updated
   notes on appropriate use, are in `the caching documentation`_.

Removal of deprecated features
    A number of features and methods which had previously been marked
    as deprecated, and which were scheduled for removal prior to the
    1.0 release, are no longer present in Django. These include
    imports of the form library from ``django.newforms`` (now located
    simply at ``django.forms``), the ``form_for_model`` and
    ``form_for_instance`` helper functions (which have been replaced
    by ``ModelForm``) and a number of deprecated features which were
    replaced by the dispatcher, file-uploading and file-storage
    refactorings introduced in the Django 1.0 alpha releases. A full
    list of these and all other backwards-incompatible changes is
    available on `the Django wiki`_.

A number of other improvements and bugfixes have also been included:
some tricky cases involving case-sensitivity in differing MySQL
collations have been resolved, Windows packaging and installation has
been improved and the method by which Django generates unique session
identifiers has been made much more robust.

.. _the 1.0 alpha 1 release notes: ../release_notes_1.0_alpha/
.. _the 1.0 alpha 2 release notes: ../release_notes_1.0_alpha_2/
.. _the documentation for generic relations: ../contenttypes/#generic-relations
.. _the admin documentation: ../admin/#modeladmin-methods
.. _the database API documentation: ../db-api/#forcing-an-insert-or-update
.. _the caching documentation: ../cache/#the-per-site-cache
.. _the Django wiki: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Removedseveralmoredeprecatedfeaturesfor1.0


The Django 1.0 roadmap
======================

One of the primary goals of this beta release is to focus attention on
the remaining features to be implemented for Django 1.0, and on the
{'fraction_non_alphanumeric': 0.07754927163667523, 'fraction_numerical': 0.011996572407883462, 'mean_word_length': 4.213288665549972, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5980795', 'n_tokens_mistral': 2352, 'n_tokens_neox': 2177, 'n_words': 1247}