2008-08-15 11:56:48 +08:00
|
|
|
===============================
|
|
|
|
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
|
2008-08-15 11:58:35 +08:00
|
|
|
identifiers has been made much more robust.
|
2008-08-15 11:56:48 +08:00
|
|
|
|
|
|
|
.. _the 1.0 alpha 1 release notes: ../release_notes_1.0_alpha/
|
2008-08-15 11:59:32 +08:00
|
|
|
.. _the 1.0 alpha 2 release notes: ../release_notes_1.0_alpha_2/
|
2008-08-15 11:56:48 +08:00
|
|
|
.. _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
|
|
|
|
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:
|
|
|
|
|
|
|
|
http://code.djangoproject.com/wiki/VersionOneRoadmap
|
|
|
|
|
|
|
|
|
|
|
|
What you can do to help
|
|
|
|
=======================
|
|
|
|
|
|
|
|
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 alpha
|
|
|
|
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:
|
|
|
|
|
|
|
|
http://code.djangoproject.com/timeline
|
|
|
|
|
|
|
|
Please open new tickets if no existing ticket corresponds to a problem
|
|
|
|
you're running into.
|
|
|
|
|
|
|
|
Additionally, discussion of Django development, including progress
|
|
|
|
toward the 1.0 release, takes place daily on the django-developers
|
|
|
|
mailing list:
|
|
|
|
|
|
|
|
http://groups.google.com/group/django-developers
|
|
|
|
|
|
|
|
...and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If
|
|
|
|
you're interested in helping out with Django's development, feel free
|
|
|
|
to join the discussions there.
|
|
|
|
|
|
|
|
Django's online documentation also includes pointers on how to
|
|
|
|
contribute to Django:
|
|
|
|
|
|
|
|
http://www.djangoproject.com/documentation/contributing/
|
|
|
|
|
|
|
|
Contributions on any level -- developing code, writing
|
|
|
|
documentation or simply triaging tickets and helping to test proposed
|
|
|
|
bugfixes -- are always welcome and appreciated.
|