1.6.txt 5.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129
  1. ============================================
  2. Django 1.6 release notes - UNDER DEVELOPMENT
  3. ============================================
  4. Welcome to Django 1.6!
  5. These release notes cover the `new features`_, as well as some `backwards
  6. incompatible changes`_ you'll want to be aware of when upgrading from Django
  7. 1.5 or older versions. We've also dropped some features, which are detailed in
  8. :doc:`our deprecation plan </internals/deprecation>`, and we've `begun the
  9. deprecation process for some features`_.
  10. .. _`new features`: `What's new in Django 1.6`_
  11. .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.6`_
  12. .. _`begun the deprecation process for some features`: `Features deprecated in 1.6`_
  13. What's new in Django 1.6
  14. ========================
  15. Simplified default project and app templates
  16. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  17. The default templates used by :djadmin:`startproject` and :djadmin:`startapp`
  18. have been simplified and modernized. The :doc:`admin
  19. </ref/contrib/admin/index>` is now enabled by default in new projects; the
  20. :doc:`sites </ref/contrib/sites>` framework no longer is. :ref:`Language
  21. detection <how-django-discovers-language-preference>` and :ref:`clickjacking
  22. prevention <clickjacking-prevention>` are turned on.
  23. If the default templates don't suit your tastes, you can use :ref:`custom
  24. project and app templates <custom-app-and-project-templates>`.
  25. Minor features
  26. ~~~~~~~~~~~~~~
  27. * Authentication backends can raise ``PermissionDenied`` to immediately fail
  28. the authentication chain.
  29. * The ``assertQuerysetEqual()`` now checks for undefined order and raises
  30. ``ValueError`` if undefined order is spotted. The order is seen as
  31. undefined if the given ``QuerySet`` isn't ordered and there are more than
  32. one ordered values to compare against.
  33. * Added :meth:`~django.db.models.query.QuerySet.earliest` for symmetry with
  34. :meth:`~django.db.models.query.QuerySet.latest`.
  35. * The default widgets for :class:`~django.forms.EmailField` and
  36. :class:`~django.forms.URLField` use the new type attributes available in
  37. HTML5 (type='email', type='url').
  38. * The ``number`` argument for :ref:`lazy plural translations
  39. <lazy-plural-translations>` can be provided at translation time rather than
  40. at definition time.
  41. * For custom management commands: Verification of the presence of valid
  42. settings in commands that ask for it by using the
  43. :attr:`~django.core.management.BaseCommand.can_import_settings` internal
  44. option is now performed independently from handling of the locale that
  45. should be active during the execution of the command. The latter can now be
  46. influenced by the new
  47. :attr:`~django.core.management.BaseCommand.leave_locale_alone` internal
  48. option. See :ref:`management-commands-and-locales` for more details.
  49. Backwards incompatible changes in 1.6
  50. =====================================
  51. * The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more -
  52. it is only usable as a marker class for checking if
  53. :meth:`~django.db.models.query.QuerySet.none` has been called:
  54. ``isinstance(qs.none(), EmptyQuerySet)``
  55. * If your CSS/Javascript code used to access HTML input widgets by type, you
  56. should review it as ``type='text'`` widgets might be now output as
  57. ``type='email'`` or ``type='url'`` depending on their corresponding field type.
  58. * Extraction of translatable literals from templates with the
  59. :djadmin:`makemessages` command now correctly detects i18n constructs when
  60. they are located after a ``{#`` / ``#}``-type comment on the same line. E.g.:
  61. .. code-block:: html+django
  62. {# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}
  63. * (Related to the above item.) Validation of the placement of
  64. :ref:`translator-comments-in-templates` specified using ``{#`` / ``#}`` is now
  65. stricter. All translator comments not located at the end of their respective
  66. lines in a template are ignored and a warning is generated by
  67. :djadmin:`makemessages` when it finds them. E.g.:
  68. .. code-block:: html+django
  69. {# Translators: This is ignored #}{% trans "Translate me" %}
  70. {{ title }}{# Translators: Extracted and associated with 'Welcome' below #}
  71. <h1>{% trans "Welcome" %}</h1>
  72. .. warning::
  73. In addition to the changes outlined in this section, be sure to review the
  74. :doc:`deprecation plan </internals/deprecation>` for any features that
  75. have been removed. If you haven't updated your code within the
  76. deprecation timeline for a given feature, its removal may appear as a
  77. backwards incompatible change.
  78. Features deprecated in 1.6
  79. ==========================
  80. ``SEND_BROKEN_LINK_EMAILS`` setting
  81. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  82. :class:`~django.middleware.common.CommonMiddleware` used to provide basic
  83. reporting of broken links by email when ``SEND_BROKEN_LINK_EMAILS`` is set to
  84. ``True``.
  85. Because of intractable ordering problems between
  86. :class:`~django.middleware.common.CommonMiddleware` and
  87. :class:`~django.middleware.locale.LocaleMiddleware`, this feature was split
  88. out into a new middleware:
  89. :class:`~django.middleware.common.BrokenLinkEmailsMiddleware`.
  90. If you're relying on this feature, you should add
  91. ``'django.middleware.common.BrokenLinkEmailsMiddleware'`` to your
  92. :setting:`MIDDLEWARE_CLASSES` setting and remove ``SEND_BROKEN_LINK_EMAILS``
  93. from your settings.
  94. ``_has_changed`` method on widgets
  95. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  96. If you defined your own form widgets and defined the ``_has_changed`` method
  97. on a widget, you should now define this method on the form field itself.