diff options
Diffstat (limited to 'parts/django/docs/releases/1.0.txt')
| -rw-r--r-- | parts/django/docs/releases/1.0.txt | 246 |
1 files changed, 0 insertions, 246 deletions
diff --git a/parts/django/docs/releases/1.0.txt b/parts/django/docs/releases/1.0.txt deleted file mode 100644 index a2b6083..0000000 --- a/parts/django/docs/releases/1.0.txt +++ /dev/null @@ -1,246 +0,0 @@ -======================== -Django 1.0 release notes -======================== - -Welcome to Django 1.0! - -We've been looking forward to this moment for over three years, and it's finally -here. Django 1.0 represents a the largest milestone in Django's development to -date: a Web framework that a group of perfectionists can truly be proud of. - -Django 1.0 represents over three years of community development as an Open -Source project. Django's received contributions from hundreds of developers, -been translated into fifty languages, and today is used by developers on every -continent and in every kind of job. - -An interesting historical note: when Django was first released in July 2005, the -initial released version of Django came from an internal repository at revision -number 8825. Django 1.0 represents revision 8961 of our public repository. It -seems fitting that our 1.0 release comes at the moment where community -contributions overtake those made privately. - -Stability and forwards-compatibility -==================================== - -:doc:`The release of Django 1.0 </releases/1.0>` comes with a promise of API -stability and forwards-compatibility. In a nutshell, this means that code you -develop against Django 1.0 will continue to work against 1.1 unchanged, and you -should need to make only minor changes for any 1.X release. - -See the :doc:`API stability guide </misc/api-stability>` for full details. - -Backwards-incompatible changes -============================== - -Django 1.0 has a number of backwards-incompatible changes from Django 0.96. If -you have apps written against Django 0.96 that you need to port, see our -detailed porting guide: - -.. toctree:: - :maxdepth: 1 - - 1.0-porting-guide - -A complete list of backwards-incompatible changes can be found at -http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges. - -What's new in Django 1.0 -======================== - -A *lot*! - -Since Django 0.96, we've made over 4,000 code commits, fixed more than 2,000 -bugs, and edited, added, or removed around 350,000 lines of code. We've also -added 40,000 lines of new documentation, and greatly improved what was already -there. - -In fact, new documentation is one of our favorite features of Django 1.0, so we -might as well start there. First, there's a new documentation site: - - http://docs.djangoproject.com/ - -The documentation has been greatly improved, cleaned up, and generally made -awesome. There's now dedicated search, indexes, and more. - -We can't possibly document everything that's new in 1.0, but the documentation -will be your definitive guide. Anywhere you see something like: - -.. versionadded:: 1.0 - This feature is new in Django 1.0 - -You'll know that you're looking at something new or changed. - -The other major highlights of Django 1.0 are: - -Re-factored admin application ------------------------------ - -The Django administrative interface (``django.contrib.admin``) has been -completely refactored; admin definitions are now completely decoupled from model -definitions (no more ``class Admin`` declaration in models!), rewritten to use -Django's new form-handling library (introduced in the 0.96 release as -``django.newforms``, and now available as simply ``django.forms``) and -redesigned with extensibility and customization in mind. Full documentation for -the admin application is available online in the official Django documentation: - -See the :doc:`admin reference </ref/contrib/admin/index>` for details - -Improved Unicode handling -------------------------- - -Django's internals have been refactored to use Unicode throughout; this -drastically simplifies the task of dealing with non-Western-European content and -data in Django. Additionally, utility functions have been provided to ease -interoperability with third-party libraries and systems which may or may not -handle Unicode gracefully. Details are available in Django's Unicode-handling -documentation. - -See :doc:`/ref/unicode`. - -An improved ORM ---------------- - -Django's object-relational mapper -- the component which provides the mapping -between Django model classes and your database, and which mediates your database -queries -- has been dramatically improved by a massive refactoring. For most -users of Django this is backwards-compatible; the public-facing API for database -querying underwent a few minor changes, but most of the updates took place in -the ORM's internals. A guide to the changes, including backwards-incompatible -modifications and mentions of new features opened up by this refactoring, is -`available on the Django wiki`__. - -__ http://code.djangoproject.com/wiki/QuerysetRefactorBranch - -Automatic escaping of template variables ----------------------------------------- - -To provide improved security against cross-site scripting (XSS) vulnerabilities, -Django's template system now automatically escapes the output of variables. This -behavior is configurable, and allows both variables and larger template -constructs to be marked as safe (requiring no escaping) or unsafe (requiring -escaping). A full guide to this feature is in the documentation for the -:ttag:`autoescape` tag. - -``django.contrib.gis`` (GeoDjango) ----------------------------------- - -A project over a year in the making, this adds world-class GIS (`Geographic -Information Systems`_) support to Django, in the form of a ``contrib`` -application. Its documentation is currently being maintained externally, and -will be merged into the main Django documentation shortly. Huge thanks go to -Justin Bronn, Jeremy Dunck, Brett Hoerner and Travis Pinney for their efforts in -creating and completing this feature. - -See http://geodjango.org/ for details. - -.. _Geographic Information Systems: http://en.wikipedia.org/wiki/Geographic_information_system - -Pluggable file storage ----------------------- - -Django's built-in ``FileField`` and ``ImageField`` now can take advantage of -pluggable file-storage backends, allowing extensive customization of where and -how uploaded files get stored by Django. For details, see :doc:`the files -documentation </topics/files>`; big thanks go to Marty Alchin for putting in the -hard work to get this completed. - -Jython compatibility --------------------- - -Thanks to a lot of work from Leo Soto during a Google Summer of Code project, -Django's codebase has been refactored to remove incompatibilities with -`Jython`_, an implementation of Python written in Java, which runs Python code -on the Java Virtual Machine. Django is now compatible with the forthcoming -Jython 2.5 release. - -See :doc:`/howto/jython`. - -.. _Jython: http://www.jython.org/ - -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 -:ref:`the documentation for generic relations <generic-relations>` for details. - -``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. - -See :ref:`ref-models-force-insert` for details. - -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 :doc:`the -caching documentation </topics/cache>`. - -Refactored ``django.contrib.comments`` --------------------------------------- - -As part of a Google Summer of Code project, Thejaswi Puthraya carried out a -major rewrite and refactoring of Django's bundled comment system, greatly -increasing its flexibility and customizability. :doc:`Full documentation -</ref/contrib/comments/index>` is available, as well as :doc:`an upgrade guide -</ref/contrib/comments/upgrade>` if you were using the previous incarnation of -the comments application. - -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. - -Known issues -============ - -We've done our best to make Django 1.0 as solid as possible, but unfortunately -there are a couple of issues that we know about in the release. - -Multi-table model inheritance with ``to_field`` ------------------------------------------------ - -If you're using :ref:`multiple table model inheritance -<multi-table-inheritance>`, be aware of this caveat: child models using a custom -``parent_link`` and ``to_field`` will cause database integrity errors. A set of -models like the following are **not valid**:: - - class Parent(models.Model): - name = models.CharField(max_length=10) - other_value = models.IntegerField(unique=True) - - class Child(Parent): - father = models.OneToOneField(Parent, primary_key=True, to_field="other_value", parent_link=True) - value = models.IntegerField() - -This bug will be fixed in the next release of Django. - -Caveats with support of certain databases ------------------------------------------ - -Django attempts to support as many features as possible on all database -backends. However, not all database backends are alike, and in particular many of the supported database differ greatly from version to version. It's a good idea to checkout our :doc:`notes on supported database </ref/databases>`: - - - :ref:`mysql-notes` - - :ref:`sqlite-notes` - - :ref:`oracle-notes` - |