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.

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.

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
bugs that need to be resolved before the final release. Following this
release, we’ll be conducting a series of development sprints building
up to the release-candidate stage, followed soon after by Django
1.0. The timeline is projected to be:

August 15, 2008: Sprint (based in Austin, Texas, USA, and online).

August 17, 2008: Sprint (based in Tel Aviv, Israel, and online).

August 21, 2008: Django 1.0 release candidate 1. At this point,
all strings marked for translation within Django’s codebase will be
frozen, to provide contributors time to check and finalize all of
Django’s bundled translation files prior to the final 1.0 release.

August 22, 2008: Sprint (based in Portland, Oregon, USA, and online).

August 26, 2008: Django 1.0 release candidate 2.

August 30, 2008: Sprint (based in London, England, UK, and online).

September 2, 2008: Django 1.0 final release. The official Django
1.0 release party will take place during the first-ever DjangoCon,
to be held in Mountain View, California, USA, September 6-7.

Of course, like any estimated timeline, this is subject to change as
requirements dictate. The latest information will always be available
on the Django project wiki:

In order to provide a high-quality 1.0 release, we need your
help. Although this beta release is, again, not intended for
production use, you can help the Django team by trying out the beta
codebase in a safe test environment and reporting any bugs or issues
you encounter. The Django ticket tracker is the central place to
search for open issues: