1.6.txt 4.8 KB

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