PageRenderTime 15ms CodeModel.GetById 5ms app.highlight 3ms RepoModel.GetById 1ms app.codeStats 1ms

Plain Text | 153 lines | 117 code | 36 blank | 0 comment | 0 complexity | 4877290d54a129ae1cc66c10df334953 MD5 | raw file
  2Django 1.0 beta 1 release notes
  5Welcome to Django 1.0 beta 1!
  7This is the third in a series of preview/development releases leading
  8up to the eventual release of Django 1.0, currently scheduled to take
  9place in early September 2008. This releases is primarily targeted at
 10developers who are interested in testing the Django codebase and
 11helping to identify and resolve bugs prior to the final 1.0 release.
 13As such, this release is *not* intended for production use, and any
 14such use is discouraged.
 16What's new in Django 1.0 beta 1
 19Django's development trunk has been the site of nearly constant activity over
 20the past year, with several major new features landing since the 0.96 release.
 21For features which were new as of Django 1.0 alpha 1, see :doc:`the 1.0 alpha 1
 22release notes </releases/1.0-alpha-1>`. For features which were new as of Django
 231.0 alpha 2, see :doc:`the 1.0 alpha 2 release notes </releases/1.0-alpha-2>`.
 25This beta release does not contain any major new features, but does
 26include several smaller updates and improvements to Django:
 28Generic relations in forms and admin
 29    Classes are now included in ``django.contrib.contenttypes`` which
 30    can be used to support generic relations in both the admin
 31    interface and in end-user forms. See :ref:`the documentation for
 32    generic relations <generic-relations>` for details.
 34Improved flexibility in the admin
 35    Following up on the refactoring of Django's administrative
 36    interface (``django.contrib.admin``), introduced in Django 1.0
 37    alpha 1, two new hooks have been added to allow customized pre-
 38    and post-save handling of model instances in the admin. Full
 39    details are in :doc:`the admin documentation </ref/contrib/admin/index>`.
 41``INSERT``/``UPDATE`` distinction
 42    Although Django's default behavior of having a model's ``save()``
 43    method automatically determine whether to perform an ``INSERT`` or
 44    an ``UPDATE`` at the SQL level is suitable for the majority of
 45    cases, there are occasional situations where forcing one or the
 46    other is useful. As a result, models can now support an additional
 47    parameter to ``save()`` which can force a specific
 48    operation. Consult the database API documentation for details
 49    and important notes about appropriate use of this parameter.
 51Split ``CacheMiddleware``
 52   Django's ``CacheMiddleware`` has been split into three classes:
 53   ``CacheMiddleware`` itself still exists and retains all of its
 54   previous functionality, but it is now built from two separate
 55   middleware classes which handle the two parts of caching (inserting
 56   into and reading from the cache) separately, offering additional
 57   flexibility for situations where combining these functions into a
 58   single middleware posed problems. Full details, including updated
 59   notes on appropriate use, are in 
 60   :doc:`the caching documentation </topics/cache>`.
 62Removal of deprecated features
 63    A number of features and methods which had previously been marked
 64    as deprecated, and which were scheduled for removal prior to the
 65    1.0 release, are no longer present in Django. These include
 66    imports of the form library from ``django.newforms`` (now located
 67    simply at ``django.forms``), the ``form_for_model`` and
 68    ``form_for_instance`` helper functions (which have been replaced
 69    by ``ModelForm``) and a number of deprecated features which were
 70    replaced by the dispatcher, file-uploading and file-storage
 71    refactorings introduced in the Django 1.0 alpha releases. A full
 72    list of these and all other backwards-incompatible changes is
 73    available on `the Django wiki`_.
 75A number of other improvements and bugfixes have also been included:
 76some tricky cases involving case-sensitivity in differing MySQL
 77collations have been resolved, Windows packaging and installation has
 78been improved and the method by which Django generates unique session
 79identifiers has been made much more robust.
 81.. _the documentation for generic relations: ../contenttypes/#generic-relations
 82.. _the Django wiki:
 85The Django 1.0 roadmap
 88One of the primary goals of this beta release is to focus attention on
 89the remaining features to be implemented for Django 1.0, and on the
 90bugs that need to be resolved before the final release. Following this
 91release, we'll be conducting a series of development sprints building
 92up to the release-candidate stage, followed soon after by Django
 931.0. The timeline is projected to be:
 95* August 15, 2008: Sprint (based in Austin, Texas, USA, and online).
 97* August 17, 2008: Sprint (based in Tel Aviv, Israel, and online).
 99* **August 21, 2008: Django 1.0 release candidate 1.** At this point,
100  all strings marked for translation within Django's codebase will be
101  frozen, to provide contributors time to check and finalize all of
102  Django's bundled translation files prior to the final 1.0 release.
104* August 22, 2008: Sprint (based in Portland, Oregon, USA, and online).
106* **August 26, 2008: Django 1.0 release candidate 2.**
108* August 30, 2008: Sprint (based in London, England, UK, and online).
110* **September 2, 2008: Django 1.0 final release.** The official Django
111  1.0 release party will take place during the first-ever DjangoCon,
112  to be held in Mountain View, California, USA, September 6-7.
114Of course, like any estimated timeline, this is subject to change as
115requirements dictate. The latest information will always be available
116on the Django project wiki:
121What you can do to help
124In order to provide a high-quality 1.0 release, we need your
125help. Although this beta release is, again, *not* intended for
126production use, you can help the Django team by trying out the beta
127codebase in a safe test environment and reporting any bugs or issues
128you encounter. The Django ticket tracker is the central place to
129search for open issues:
133Please open new tickets if no existing ticket corresponds to a problem
134you're running into.
136Additionally, discussion of Django development, including progress
137toward the 1.0 release, takes place daily on the django-developers
138mailing list:
142...and in the ``#django-dev`` IRC channel on ````. If
143you're interested in helping out with Django's development, feel free
144to join the discussions there.
146Django's online documentation also includes pointers on how to
147contribute to Django:
149    :doc:`contributing to Django </internals/contributing>`
151Contributions on any level -- developing code, writing
152documentation or simply triaging tickets and helping to test proposed
153bugfixes -- are always welcome and appreciated.