PageRenderTime 42ms CodeModel.GetById 22ms RepoModel.GetById 0ms app.codeStats 0ms

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