1.0 beta 1 release notes

git-svn-id: http://code.djangoproject.com/svn/django/trunk@8358 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 159 insertions, 0 deletions

diff --git a/docs/release_notes_1.0_beta_1.txt b/docs/release_notes_1.0_beta_1.txt
new file mode 100644
index 0000000000..da0fb7d01b
--- /dev/null
+++ b/docs/release_notes_1.0_beta_1.txt
@@ -0,0 +1,159 @@
+===============================
+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
+identiiers 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
+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.