1.6.txt 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115
  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 managemente commands: Validation of the presence of valid settings
  32. in managements 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 should
  35. active during the execution of the command. The latter can now be influenced
  36. by the new :attr:`~django.core.management.BaseCommand.leave_locale_alone`
  37. internal option. See :ref:`management-commands-and-locales` for more details.
  38. Backwards incompatible changes in 1.6
  39. =====================================
  40. * The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more -
  41. it is only usable as a marker class for checking if
  42. :meth:`~django.db.models.query.QuerySet.none` has been called:
  43. ``isinstance(qs.none(), EmptyQuerySet)``
  44. * If your CSS/Javascript code used to access HTML input widgets by type, you
  45. should review it as ``type='text'`` widgets might be now output as
  46. ``type='email'`` or ``type='url'`` depending on their corresponding field type.
  47. * Extraction of translatable literals from templates with the
  48. :djadmin:`makemessages` command now correctly detects i18n constructs when
  49. they are located after a ``{#`` / ``#}``-type comment on the same line. E.g.:
  50. .. code-block:: html+django
  51. {# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}
  52. * (Related to the above item.) Validation of the placement of
  53. :ref:`translator-comments-in-templates` specified using ``{#`` / ``#}`` is now
  54. stricter. All translator comments not located at the end of their respective
  55. lines in a template are ignored and a warning is generated by
  56. :djadmin:`makemessages` when it finds them. E.g.:
  57. .. code-block:: html+django
  58. {# Translators: This is ignored #}{% trans "Translate me" %}
  59. {{ title }}{# Translators: Extracted and associated with 'Welcome' below #}
  60. <h1>{% trans "Welcome" %}</h1>
  61. .. warning::
  62. In addition to the changes outlined in this section, be sure to review the
  63. :doc:`deprecation plan </internals/deprecation>` for any features that
  64. have been removed. If you haven't updated your code within the
  65. deprecation timeline for a given feature, its removal may appear as a
  66. backwards incompatible change.
  67. Features deprecated in 1.6
  68. ==========================
  69. ``SEND_BROKEN_LINK_EMAILS`` setting
  70. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  71. :class:`~django.middleware.common.CommonMiddleware` used to provide basic
  72. reporting of broken links by email when ``SEND_BROKEN_LINK_EMAILS`` is set to
  73. ``True``.
  74. Because of intractable ordering problems between
  75. :class:`~django.middleware.common.CommonMiddleware` and
  76. :class:`~django.middleware.locale.LocaleMiddleware`, this feature was split
  77. out into a new middleware:
  78. :class:`~django.middleware.common.BrokenLinkEmailsMiddleware`.
  79. If you're relying on this feature, you should add
  80. ``'django.middleware.common.BrokenLinkEmailsMiddleware'`` to your
  81. :setting:`MIDDLEWARE_CLASSES` setting and remove ``SEND_BROKEN_LINK_EMAILS``
  82. from your settings.
  83. ``_has_changed`` method on widgets
  84. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  85. If you defined your own form widgets and defined the ``_has_changed`` method
  86. on a widget, you should now define this method on the form field itself.