Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Added release notes for Django 1.5 alpha 1.

Also updated 1.5-proper release notes a bit.
  • Loading branch information...
commit 137fdbeebd83e50d8c24c0b6be091e7d7088ef9a 1 parent bd6d9ea
Jacob Kaplan-Moss authored October 25, 2012
631  docs/releases/1.5-alpha-1.txt
... ...
@@ -0,0 +1,631 @@
  1
+============================================
  2
+Django 1.5 release notes - UNDER DEVELOPMENT
  3
+============================================
  4
+
  5
+October 25, 2012.
  6
+
  7
+Welcome to Django 1.5 alpha!
  8
+
  9
+This is the first in a series of preview/development releases leading up to the
  10
+eventual release of Django 1.5, scheduled for December 2012. This release is
  11
+primarily targeted at developers who are interested in trying out new features
  12
+and testing the Django codebase to help identify and resolve bugs prior to the
  13
+final 1.5 release.
  14
+
  15
+As such, this release is *not* intended for production use, and any such use
  16
+is discouraged.
  17
+
  18
+In particular, we need the community's help to test Django 1.5's new `Python 3
  19
+support`_ -- not just to report bugs on Python 3, but also regressions on Python
  20
+2. While Django is very conservative with regards to backwards compatibility,
  21
+mistakes are always possible, and it's likely that the Python 3 refactoring work
  22
+introduced some regressions.
  23
+
  24
+Django 1.5 alpha includes various `new features`_ and some minor `backwards
  25
+incompatible changes`_. There are also some features that have been dropped,
  26
+which are detailed in :doc:`our deprecation plan </internals/deprecation>`,
  27
+and we've `begun the deprecation process for some features`_.
  28
+
  29
+.. _`new features`: `What's new in Django 1.5`_
  30
+.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.5`_
  31
+.. _`begun the deprecation process for some features`: `Features deprecated in 1.5`_
  32
+
  33
+Overview
  34
+========
  35
+
  36
+The biggest new feature in Django 1.5 is the `configurable User model`_. Before
  37
+Django 1.5, applications that wanted to use Django's auth framework
  38
+(:mod:`django.contrib.auth`) were forced to use Django's definition of a "user".
  39
+In Django 1.5, you can now swap out the ``User`` model for one that you write
  40
+yourself. This could be a simple extension to the existing ``User`` model -- for
  41
+example, you could add a Twitter or Facebook ID field -- or you could completely
  42
+replace the ``User`` with one totally customized for your site.
  43
+
  44
+Django 1.5 is also the first release with `Python 3 support`_! We're labeling
  45
+this support "experimental" because we don't yet consider it production-ready,
  46
+but everything's in place for you to start porting your apps to Python 3.
  47
+Our next release, Django 1.6, will support Python 3 without reservations.
  48
+
  49
+Other notable new features in Django 1.5 include:
  50
+
  51
+* `Support for saving a subset of model's fields`_ -
  52
+  :meth:`Model.save() <django.db.models.Model.save()>` now accepts an
  53
+  ``update_fields`` argument, letting you specify which fields are
  54
+  written back to the databse when you call ``save()``. This can help
  55
+  in high-concurrancy operations, and can improve performance.
  56
+
  57
+* Better `support for streaming responses <#explicit-streaming-responses>`_ via
  58
+  the new  :class:`~django.http.StreamingHttpResponse` response class.
  59
+
  60
+* `GeoDjango`_ now supports PostGIS 2.0.
  61
+
  62
+* ... and more; `see below <#what-s-new-in-django-1-5>`_.
  63
+
  64
+Wherever possible we try to introduce new features in a backwards-compatible
  65
+manner per :doc:`our API stability policy </misc/api-stability>` policy.
  66
+However, as with previous releases, Django 1.5 ships with some minor
  67
+`backwards incompatible changes`_; people upgrading from previous versions
  68
+of Django should read that list carefully.
  69
+
  70
+One deprecated feature worth noting is the shift to "new-style" :ttag:`url` tag.
  71
+Prior to Django 1.3, syntax like ``{% url myview %}`` was interpreted
  72
+incorrectly (Django considered ``"myview"`` to be a literal name of a view, not
  73
+a template variable named ``myview``). Django 1.3 and above introduced the
  74
+``{% load url from future %}`` syntax to bring in the corrected behavior where
  75
+``myview`` was seen as a variable.
  76
+
  77
+The upshot of this is that if you are not using ``{% load url from future %}``
  78
+in your templates, you'll need to change tags like ``{% url myview %}`` to
  79
+``{% url "myview" %}``. If you *were* using ``{% load url from future %}`` you
  80
+can simply remove that line under Django 1.5
  81
+
  82
+Python compatibility
  83
+====================
  84
+
  85
+Django 1.5 requires Python 2.6.5 or above, though we **highly recommended**
  86
+Python 2.7.3 or above. Support for Python 2.5 and below as been dropped.
  87
+
  88
+This change should affect only a small number of Django users, as most
  89
+operating-system vendors today are shipping Python 2.6 or newer as their default
  90
+version. If you're still using Python 2.5, however, you'll need to stick to
  91
+Django 1.4 until you can upgrade your Python version. Per :doc:`our support
  92
+policy </internals/release-process>`, Django 1.4 will continue to receive
  93
+security support until the release of Django 1.6.
  94
+
  95
+Django 1.5 does not run on a Jython final release, because Jython's latest
  96
+release doesn't currently support Python 2.6. However, Jython currently does
  97
+offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha
  98
+release.
  99
+
  100
+Python 3 support
  101
+~~~~~~~~~~~~~~~~
  102
+
  103
+Django 1.5 introduces support for Python 3 - specifically, Python
  104
+3.2 and above. This comes in the form of a **single** codebase; you don't
  105
+need to install a different version of Django on Python 3. This means that
  106
+you can write application targeted for just Python 2, just Python 3, or single
  107
+applications that support both platforms.
  108
+
  109
+However, we're labling this support "experimental" for now: although it's
  110
+receved extensive testing via our automated test suite, it's recieved very
  111
+little real-world testing. We've done our best to eliminate bugs, but we can't
  112
+be sure we covered all possible uses of Django. Further, Django's more than a
  113
+web framework; it's an ecosystem of pluggable components. At this point, very
  114
+few third-party applications have been ported to Python 3, so it's unliukely
  115
+that a real-world application will have all its dependecies satisfied under
  116
+Python 3.
  117
+
  118
+Thus, we're recommending that Django 1.5 not be used in production under Python
  119
+3. Instead, use this oportunity to begin :doc:`porting applications to Python 3
  120
+</topics/python3>`. If you're an author of a pluggable component, we encourage you
  121
+to start porting now.
  122
+
  123
+We plan to offer first-class, production-ready support for Python 3 in our next
  124
+release, Django 1.6.
  125
+
  126
+What's new in Django 1.5
  127
+========================
  128
+
  129
+Configurable User model
  130
+~~~~~~~~~~~~~~~~~~~~~~~
  131
+
  132
+In Django 1.5, you can now use your own model as the store for user-related
  133
+data. If your project needs a username with more than 30 characters, or if
  134
+you want to store usernames in a format other than first name/last name, or
  135
+you want to put custom profile information onto your User object, you can
  136
+now do so.
  137
+
  138
+If you have a third-party reusable application that references the User model,
  139
+you may need to make some changes to the way you reference User instances. You
  140
+should also document any specific features of the User model that your
  141
+application relies upon.
  142
+
  143
+See the :ref:`documentation on custom User models <auth-custom-user>` for
  144
+more details.
  145
+
  146
+Support for saving a subset of model's fields
  147
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  148
+
  149
+The method :meth:`Model.save() <django.db.models.Model.save()>` has a new
  150
+keyword argument ``update_fields``. By using this argument it is possible to
  151
+save only a select list of model's fields. This can be useful for performance
  152
+reasons or when trying to avoid overwriting concurrent changes.
  153
+
  154
+Deferred instances (those loaded by .only() or .defer()) will automatically
  155
+save just the loaded fields. If any field is set manually after load, that
  156
+field will also get updated on save.
  157
+
  158
+See the :meth:`Model.save() <django.db.models.Model.save()>` documentation for
  159
+more details.
  160
+
  161
+Caching of related model instances
  162
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  163
+
  164
+When traversing relations, the ORM will avoid re-fetching objects that were
  165
+previously loaded. For example, with the tutorial's models::
  166
+
  167
+    >>> first_poll = Poll.objects.all()[0]
  168
+    >>> first_choice = first_poll.choice_set.all()[0]
  169
+    >>> first_choice.poll is first_poll
  170
+    True
  171
+
  172
+In Django 1.5, the third line no longer triggers a new SQL query to fetch
  173
+``first_choice.poll``; it was set by the second line.
  174
+
  175
+For one-to-one relationships, both sides can be cached. For many-to-one
  176
+relationships, only the single side of the relationship can be cached. This
  177
+is particularly helpful in combination with ``prefetch_related``.
  178
+
  179
+Explicit support for streaming responses
  180
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  181
+
  182
+Before Django 1.5, it was possible to create a streaming response by passing
  183
+an iterator to :class:`~django.http.HttpResponse`. But this was unreliable:
  184
+any middleware that accessed the :attr:`~django.http.HttpResponse.content`
  185
+attribute would consume the iterator prematurely.
  186
+
  187
+You can now explicitly generate a streaming response with the new
  188
+:class:`~django.http.StreamingHttpResponse` class. This class exposes a
  189
+:class:`~django.http.StreamingHttpResponse.streaming_content` attribute which
  190
+is an iterator.
  191
+
  192
+Since :class:`~django.http.StreamingHttpResponse` does not have a ``content``
  193
+attribute, middleware that needs access to the response content must test for
  194
+streaming responses and behave accordingly. See :ref:`response-middleware` for
  195
+more information.
  196
+
  197
+``{% verbatim %}`` template tag
  198
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  199
+
  200
+To make it easier to deal with javascript templates which collide with Django's
  201
+syntax, you can now use the :ttag:`verbatim` block tag to avoid parsing the
  202
+tag's content.
  203
+
  204
+Retrieval of ``ContentType`` instances associated with proxy models
  205
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  206
+
  207
+The methods :meth:`ContentTypeManager.get_for_model() <django.contrib.contenttypes.models.ContentTypeManager.get_for_model()>`
  208
+and :meth:`ContentTypeManager.get_for_models() <django.contrib.contenttypes.models.ContentTypeManager.get_for_models()>`
  209
+have a new keyword argument – respectively ``for_concrete_model`` and ``for_concrete_models``.
  210
+By passing ``False`` using this argument it is now possible to retreive the
  211
+:class:`ContentType <django.contrib.contenttypes.models.ContentType>`
  212
+associated with proxy models.
  213
+
  214
+New ``view`` variable in class-based views context
  215
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  216
+
  217
+In all :doc:`generic class-based views </topics/class-based-views/index>`
  218
+(or any class-based view inheriting from ``ContextMixin``), the context dictionary
  219
+contains a ``view`` variable that points to the ``View`` instance.
  220
+
  221
+GeoDjango
  222
+~~~~~~~~~
  223
+
  224
+* :class:`~django.contrib.gis.geos.LineString` and
  225
+  :class:`~django.contrib.gis.geos.MultiLineString` GEOS objects now support the
  226
+  :meth:`~django.contrib.gis.geos.GEOSGeometry.interpolate()` and
  227
+  :meth:`~django.contrib.gis.geos.GEOSGeometry.project()` methods
  228
+  (so-called linear referencing).
  229
+
  230
+* The wkb and hex properties of `GEOSGeometry` objects preserve the Z dimension.
  231
+
  232
+* Support for PostGIS 2.0 has been added and support for GDAL < 1.5 has been
  233
+  dropped.
  234
+
  235
+Minor features
  236
+~~~~~~~~~~~~~~
  237
+
  238
+Django 1.5 also includes several smaller improvements worth noting:
  239
+
  240
+* The template engine now interprets ``True``, ``False`` and ``None`` as the
  241
+  corresponding Python objects.
  242
+
  243
+* :mod:`django.utils.timezone` provides a helper for converting aware
  244
+  datetimes between time zones. See :func:`~django.utils.timezone.localtime`.
  245
+
  246
+* The generic views support OPTIONS requests.
  247
+
  248
+* Management commands do not raise ``SystemExit`` any more when called by code
  249
+  from :ref:`call_command <call-command>`. Any exception raised by the command
  250
+  (mostly :ref:`CommandError <ref-command-exceptions>`) is propagated.
  251
+
  252
+* The dumpdata management command outputs one row at a time, preventing
  253
+  out-of-memory errors when dumping large datasets.
  254
+
  255
+* In the localflavor for Canada, "pq" was added to the acceptable codes for
  256
+  Quebec. It's an old abbreviation.
  257
+
  258
+* The :ref:`receiver <connecting-receiver-functions>` decorator is now able to
  259
+  connect to more than one signal by supplying a list of signals.
  260
+
  261
+* In the admin, you can now filter users by groups which they are members of.
  262
+
  263
+* :meth:`QuerySet.bulk_create()
  264
+  <django.db.models.query.QuerySet.bulk_create>` now has a batch_size
  265
+  argument. By default the batch_size is unlimited except for SQLite where
  266
+  single batch is limited so that 999 parameters per query isn't exceeded.
  267
+
  268
+* The :setting:`LOGIN_URL` and :setting:`LOGIN_REDIRECT_URL` settings now also
  269
+  accept view function names and
  270
+  :ref:`named URL patterns <naming-url-patterns>`. This allows you to reduce
  271
+  configuration duplication. More information can be found in the
  272
+  :func:`~django.contrib.auth.decorators.login_required` documentation.
  273
+
  274
+* Django now provides a mod_wsgi :doc:`auth handler
  275
+  </howto/deployment/wsgi/apache-auth>`.
  276
+
  277
+* The :meth:`QuerySet.delete() <django.db.models.query.QuerySet.delete>`
  278
+  and :meth:`Model.delete() <django.db.models.Model.delete()>` can now take
  279
+  fast-path in some cases. The fast-path allows for less queries and less
  280
+  objects fetched into memory. See :meth:`QuerySet.delete()
  281
+  <django.db.models.query.QuerySet.delete>` for details.
  282
+
  283
+* An instance of :class:`~django.core.urlresolvers.ResolverMatch` is stored on
  284
+  the request as ``resolver_match``.
  285
+
  286
+* By default, all logging messages reaching the `django` logger when
  287
+  :setting:`DEBUG` is `True` are sent to the console (unless you redefine the
  288
+  logger in your :setting:`LOGGING` setting).
  289
+
  290
+* When using :class:`~django.template.RequestContext`, it is now possible to
  291
+  look up permissions by using ``{% if 'someapp.someperm' in perms %}``
  292
+  in templates.
  293
+
  294
+* It's not required any more to have ``404.html`` and ``500.html`` templates in
  295
+  the root templates directory. Django will output some basic error messages for
  296
+  both situations when those templates are not found. Of course, it's still
  297
+  recommended as good practice to provide those templates in order to present
  298
+  pretty error pages to the user.
  299
+
  300
+* :mod:`django.contrib.auth` provides a new signal that is emitted
  301
+  whenever a user fails to login successfully. See
  302
+  :data:`~django.contrib.auth.signals.user_login_failed`
  303
+
  304
+* The loaddata management command now supports an `ignorenonexistent` option to
  305
+  ignore data for fields that no longer exist.
  306
+
  307
+* :meth:`~django.test.SimpleTestCase.assertXMLEqual` and
  308
+  :meth:`~django.test.SimpleTestCase.assertXMLNotEqual` new assertions allow
  309
+  you to test equality for XML content at a semantic level, without caring for
  310
+  syntax differences (spaces, attribute order, etc.).
  311
+
  312
+Backwards incompatible changes in 1.5
  313
+=====================================
  314
+
  315
+.. warning::
  316
+
  317
+    In addition to the changes outlined in this section, be sure to review the
  318
+    :doc:`deprecation plan </internals/deprecation>` for any features that
  319
+    have been removed. If you haven't updated your code within the
  320
+    deprecation timeline for a given feature, its removal may appear as a
  321
+    backwards incompatible change.
  322
+
  323
+Context in year archive class-based views
  324
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  325
+
  326
+For consistency with the other date-based generic views,
  327
+:class:`~django.views.generic.dates.YearArchiveView` now passes ``year`` in
  328
+the context as a :class:`datetime.date` rather than a string.  If you are
  329
+using ``{{ year }}`` in your templates, you must replace it with ``{{
  330
+year|date:"Y" }}``.
  331
+
  332
+``next_year`` and ``previous_year`` were also added in the context. They are
  333
+calculated according to ``allow_empty`` and ``allow_future``.
  334
+
  335
+Context in year and month archive class-based views
  336
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  337
+
  338
+:class:`~django.views.generic.dates.YearArchiveView` and
  339
+:class:`~django.views.generic.dates.MonthArchiveView` were documented to
  340
+provide a ``date_list`` sorted in ascending order in the context, like their
  341
+function-based predecessors, but it actually was in descending order. In 1.5,
  342
+the documented order was restored. You may want to add (or remove) the
  343
+``reversed`` keyword when you're iterating on ``date_list`` in a template::
  344
+
  345
+    {% for date in date_list reversed %}
  346
+
  347
+:class:`~django.views.generic.dates.ArchiveIndexView` still provides a
  348
+``date_list`` in descending order.
  349
+
  350
+Context in TemplateView
  351
+~~~~~~~~~~~~~~~~~~~~~~~
  352
+
  353
+For consistency with the design of the other generic views,
  354
+:class:`~django.views.generic.base.TemplateView` no longer passes a ``params``
  355
+dictionary into the context, instead passing the variables from the URLconf
  356
+directly into the context.
  357
+
  358
+Non-form data in HTTP requests
  359
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  360
+
  361
+:attr:`request.POST <django.http.HttpRequest.POST>` will no longer include data
  362
+posted via HTTP requests with non form-specific content-types in the header.
  363
+In prior versions, data posted with content-types other than
  364
+``multipart/form-data`` or ``application/x-www-form-urlencoded`` would still
  365
+end up represented in the :attr:`request.POST <django.http.HttpRequest.POST>`
  366
+attribute. Developers wishing to access the raw POST data for these cases,
  367
+should use the :attr:`request.body <django.http.HttpRequest.body>` attribute
  368
+instead.
  369
+
  370
+OPTIONS, PUT and DELETE requests in the test client
  371
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  372
+
  373
+Unlike GET and POST, these HTTP methods aren't implemented by web browsers.
  374
+Rather, they're used in APIs, which transfer data in various formats such as
  375
+JSON or XML. Since such requests may contain arbitrary data, Django doesn't
  376
+attempt to decode their body.
  377
+
  378
+However, the test client used to build a query string for OPTIONS and DELETE
  379
+requests like for GET, and a request body for PUT requests like for POST. This
  380
+encoding was arbitrary and inconsistent with Django's behavior when it
  381
+receives the requests, so it was removed in Django 1.5.
  382
+
  383
+If you were using the ``data`` parameter in an OPTIONS or a DELETE request,
  384
+you must convert it to a query string and append it to the ``path`` parameter.
  385
+
  386
+If you were using the ``data`` parameter in a PUT request without a
  387
+``content_type``, you must encode your data before passing it to the test
  388
+client and set the ``content_type`` argument.
  389
+
  390
+System version of :mod:`simplejson` no longer used
  391
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  392
+
  393
+As explained below, Django 1.5 deprecates
  394
+:mod:`django.utils.simplejson` in favor of Python 2.6's built-in :mod:`json`
  395
+module. In theory, this change is harmless. Unfortunately, because of
  396
+incompatibilities between versions of :mod:`simplejson`, it may trigger errors
  397
+in some circumstances.
  398
+
  399
+JSON-related features in Django 1.4 always used :mod:`django.utils.simplejson`.
  400
+This module was actually:
  401
+
  402
+- A system version of :mod:`simplejson`, if one was available (ie. ``import
  403
+  simplejson`` works), if it was more recent than Django's built-in copy or it
  404
+  had the C speedups, or
  405
+- The :mod:`json` module from the standard library, if it was available (ie.
  406
+  Python 2.6 or greater), or
  407
+- A built-in copy of version 2.0.7 of :mod:`simplejson`.
  408
+
  409
+In Django 1.5, those features use Python's :mod:`json` module, which is based
  410
+on version 2.0.9 of :mod:`simplejson`.
  411
+
  412
+There are no known incompatibilities between Django's copy of version 2.0.7 and
  413
+Python's copy of version 2.0.9. However, there are some incompatibilities
  414
+between other versions of :mod:`simplejson`:
  415
+
  416
+- While the :mod:`simplejson` API is documented as always returning unicode
  417
+  strings, the optional C implementation can return a byte string. This was
  418
+  fixed in Python 2.7.
  419
+- :class:`simplejson.JSONEncoder` gained a ``namedtuple_as_object`` keyword
  420
+  argument in version 2.2.
  421
+
  422
+More information on these incompatibilities is available in `ticket #18023`_.
  423
+
  424
+The net result is that, if you have installed :mod:`simplejson` and your code
  425
+uses Django's serialization internals directly -- for instance
  426
+:class:`django.core.serializers.json.DjangoJSONEncoder`, the switch from
  427
+:mod:`simplejson` to :mod:`json` could break your code. (In general, changes to
  428
+internals aren't documented; we're making an exception here.)
  429
+
  430
+At this point, the maintainers of Django believe that using :mod:`json` from
  431
+the standard library offers the strongest guarantee of backwards-compatibility.
  432
+They recommend to use it from now on.
  433
+
  434
+.. _ticket #18023: https://code.djangoproject.com/ticket/18023#comment:10
  435
+
  436
+String types of hasher method parameters
  437
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  438
+
  439
+If you have written a :ref:`custom password hasher <auth_password_storage>`,
  440
+your ``encode()``, ``verify()`` or ``safe_summary()`` methods should accept
  441
+Unicode parameters (``password``, ``salt`` or ``encoded``). If any of the
  442
+hashing methods need byte strings, you can use the
  443
+:func:`~django.utils.encoding.force_bytes` utility to encode the strings.
  444
+
  445
+Validation of previous_page_number and next_page_number
  446
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  447
+
  448
+When using :doc:`object pagination </topics/pagination>`,
  449
+the ``previous_page_number()`` and ``next_page_number()`` methods of the
  450
+:class:`~django.core.paginator.Page` object did not check if the returned
  451
+number was inside the existing page range.
  452
+It does check it now and raises an :exc:`InvalidPage` exception when the number
  453
+is either too low or too high.
  454
+
  455
+Behavior of autocommit database option on PostgreSQL changed
  456
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  457
+
  458
+PostgreSQL's autocommit option didn't work as advertised previously. It did
  459
+work for single transaction block, but after the first block was left the
  460
+autocommit behavior was never restored. This bug is now fixed in 1.5. While
  461
+this is only a bug fix, it is worth checking your applications behavior if
  462
+you are using PostgreSQL together with the autocommit option.
  463
+
  464
+Session not saved on 500 responses
  465
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  466
+
  467
+Django's session middleware will skip saving the session data if the
  468
+response's status code is 500.
  469
+
  470
+Email checks on failed admin login
  471
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  472
+
  473
+Prior to Django 1.5, if you attempted to log into the admin interface and
  474
+mistakenly used your email address instead of your username, the admin
  475
+interface would provide a warning advising that your email address was
  476
+not your username. In Django 1.5, the introduction of
  477
+:ref:`custom User models <auth-custom-user>` has required the removal of this
  478
+warning. This doesn't change the login behavior of the admin site; it only
  479
+affects the warning message that is displayed under one particular mode of
  480
+login failure.
  481
+
  482
+Changes in tests execution
  483
+~~~~~~~~~~~~~~~~~~~~~~~~~~
  484
+
  485
+Some changes have been introduced in the execution of tests that might be
  486
+backward-incompatible for some testing setups:
  487
+
  488
+Database flushing in ``django.test.TransactionTestCase``
  489
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  490
+
  491
+Previously, the test database was truncated *before* each test run in a
  492
+:class:`~django.test.TransactionTestCase`.
  493
+
  494
+In order to be able to run unit tests in any order and to make sure they are
  495
+always isolated from each other, :class:`~django.test.TransactionTestCase` will
  496
+now reset the database *after* each test run instead.
  497
+
  498
+No more implict DB sequences reset
  499
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  500
+
  501
+:class:`~django.test.TransactionTestCase` tests used to reset primary key
  502
+sequences automatically together with the database flushing actions described
  503
+above.
  504
+
  505
+This has been changed so no sequences are implicitly reset. This can cause
  506
+:class:`~django.test.TransactionTestCase` tests that depend on hard-coded
  507
+primary key values to break.
  508
+
  509
+The new :attr:`~django.test.TransactionTestCase.reset_sequences` attribute can
  510
+be used to force the old behavior for :class:`~django.test.TransactionTestCase`
  511
+that might need it.
  512
+
  513
+Ordering of tests
  514
+^^^^^^^^^^^^^^^^^
  515
+
  516
+In order to make sure all ``TestCase`` code starts with a clean database,
  517
+tests are now executed in the following order:
  518
+
  519
+* First, all unittests (including :class:`unittest.TestCase`,
  520
+  :class:`~django.test.SimpleTestCase`, :class:`~django.test.TestCase` and
  521
+  :class:`~django.test.TransactionTestCase`) are run with no particular ordering
  522
+  guaranteed nor enforced among them.
  523
+
  524
+* Then any other tests (e.g. doctests) that may alter the database without
  525
+  restoring it to its original state are run.
  526
+
  527
+This should not cause any problems unless you have existing doctests which
  528
+assume a :class:`~django.test.TransactionTestCase` executed earlier left some
  529
+database state behind or unit tests that rely on some form of state being
  530
+preserved after the execution of other tests. Such tests are already very
  531
+fragile, and must now be changed to be able to run independently.
  532
+
  533
+`cleaned_data` dictionary kept for invalid forms
  534
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  535
+
  536
+The :attr:`~django.forms.Form.cleaned_data` dictionary is now always present
  537
+after form validation. When the form doesn't validate, it contains only the
  538
+fields that passed validation. You should test the success of the validation
  539
+with the :meth:`~django.forms.Form.is_valid()` method and not with the
  540
+presence or absence of the :attr:`~django.forms.Form.cleaned_data` attribute
  541
+on the form.
  542
+
  543
+Miscellaneous
  544
+~~~~~~~~~~~~~
  545
+
  546
+* :class:`django.forms.ModelMultipleChoiceField` now returns an empty
  547
+  ``QuerySet`` as the empty value instead of an empty list.
  548
+
  549
+* :func:`~django.utils.http.int_to_base36` properly raises a :exc:`TypeError`
  550
+  instead of :exc:`ValueError` for non-integer inputs.
  551
+
  552
+* The ``slugify`` template filter is now available as a standard python
  553
+  function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
  554
+  available at :func:`django.utils.html.remove_tags`.
  555
+
  556
+* Uploaded files are no longer created as executable by default. If you need
  557
+  them to be executeable change :setting:`FILE_UPLOAD_PERMISSIONS` to your
  558
+  needs. The new default value is `0666` (octal) and the current umask value
  559
+  is first masked out.
  560
+
  561
+* The :ref:`F() expressions <query-expressions>` supported bitwise operators by
  562
+  ``&`` and ``|``. These operators are now available using ``.bitand()`` and
  563
+  ``.bitor()`` instead. The removal of ``&`` and ``|`` was done to be consistent with
  564
+  :ref:`Q() expressions <complex-lookups-with-q>` and ``QuerySet`` combining where
  565
+  the operators are used as boolean AND and OR operators.
  566
+
  567
+* The :ttag:`csrf_token` template tag is no longer enclosed in a div. If you need
  568
+  HTML validation against pre-HTML5 Strict DTDs, you should add a div around it
  569
+  in your pages.
  570
+
  571
+Features deprecated in 1.5
  572
+==========================
  573
+
  574
+:setting:`AUTH_PROFILE_MODULE`
  575
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  576
+
  577
+With the introduction of :ref:`custom User models <auth-custom-user>`, there is
  578
+no longer any need for a built-in mechanism to store user profile data.
  579
+
  580
+You can still define user profiles models that have a one-to-one relation with
  581
+the User model - in fact, for many applications needing to associate data with
  582
+a User account, this will be an appropriate design pattern to follow. However,
  583
+the :setting:`AUTH_PROFILE_MODULE` setting, and the
  584
+:meth:`~django.contrib.auth.models.User.get_profile()` method for accessing
  585
+the user profile model, should not be used any longer.
  586
+
  587
+Streaming behavior of :class:`HttpResponse`
  588
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  589
+
  590
+Django 1.5 deprecates the ability to stream a response by passing an iterator
  591
+to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
  592
+:class:`~django.http.StreamingHttpResponse`. See above for more details.
  593
+
  594
+In Django 1.7 and above, the iterator will be consumed immediately by
  595
+:class:`~django.http.HttpResponse`.
  596
+
  597
+``django.utils.simplejson``
  598
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
  599
+
  600
+Since Django 1.5 drops support for Python 2.5, we can now rely on the
  601
+:mod:`json` module being available in Python's standard library, so we've
  602
+removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
  603
+instead :mod:`django.utils.simplejson`.
  604
+
  605
+Unfortunately, this change might have unwanted side-effects, because of
  606
+incompatibilities between versions of :mod:`simplejson` -- see the backwards-
  607
+incompatible changes section. If you rely on features added to :mod:`simplejson`
  608
+after it became Python's :mod:`json`, you should import :mod:`simplejson`
  609
+explicitly.
  610
+
  611
+``django.utils.encoding.StrAndUnicode``
  612
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  613
+
  614
+The :class:`~django.utils.encoding.StrAndUnicode` mix-in has been deprecated.
  615
+Define a ``__str__`` method and apply the
  616
+:func:`~django.utils.encoding.python_2_unicode_compatible` decorator instead.
  617
+
  618
+``django.utils.itercompat.product``
  619
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  620
+
  621
+The :func:`~django.utils.itercompat.product` function has been deprecated. Use
  622
+the built-in :func:`itertools.product` instead.
  623
+
  624
+
  625
+``django.utils.markup``
  626
+~~~~~~~~~~~~~~~~~~~~~~~
  627
+
  628
+The markup contrib module has been deprecated and will follow an accelerated
  629
+deprecation schedule. Direct use of python markup libraries or 3rd party tag
  630
+libraries is preferred to Django maintaining this functionality in the
  631
+framework.
97  docs/releases/1.5.txt
@@ -2,6 +2,8 @@
2 2
 Django 1.5 release notes - UNDER DEVELOPMENT
3 3
 ============================================
4 4
 
  5
+Welcome to Django 1.5!
  6
+
5 7
 These release notes cover the `new features`_, as well
6 8
 as some `backwards incompatible changes`_ you'll want to be aware of
7 9
 when upgrading from Django 1.4 or older versions. We've also dropped some
@@ -13,23 +15,98 @@ features`_.
13 15
 .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.5`_
14 16
 .. _`begun the deprecation process for some features`: `Features deprecated in 1.5`_
15 17
 
  18
+Overview
  19
+========
  20
+
  21
+The biggest new feature in Django 1.5 is the `configurable User model`_. Before
  22
+Django 1.5, applications that wanted to use Django's auth framework
  23
+(:mod:`django.contrib.auth`) were forced to use Django's definition of a "user".
  24
+In Django 1.5, you can now swap out the ``User`` model for one that you write
  25
+yourself. This could be a simple extension to the existing ``User`` model -- for
  26
+example, you could add a Twitter or Facebook ID field -- or you could completely
  27
+replace the ``User`` with one totally customized for your site.
  28
+
  29
+Django 1.5 is also the first release with `Python 3 support`_! We're labling
  30
+this support "experimental" because we don't yet consider it production-ready,
  31
+but everything's in place for you to start porting your apps to Python 3.
  32
+Our next release, Django 1.6, will support Python 3 without reservations.
  33
+
  34
+Other notable new features in Django 1.5 include:
  35
+
  36
+* `Support for saving a subset of model's fields`_ -
  37
+  :meth:`Model.save() <django.db.models.Model.save()>` now accepts an
  38
+  ``update_fields`` argument, letting you specify which fields are
  39
+  written back to the databse when you call ``save()``. This can help
  40
+  in high-concurrancy operations, and can improve performance.
  41
+
  42
+* Better `support for streaming responses <#explicit-streaming-responses>`_ via
  43
+  the new  :class:`~django.http.StreamingHttpResponse` response class.
  44
+
  45
+* `GeoDjango`_ now supports PostGIS 2.0.
  46
+
  47
+* ... and more; `see below <#what-s-new-in-django-1-5>`_.
  48
+
  49
+Wherever possible we try to introduce new features in a backwards-compatible
  50
+manner per :doc:`our API stability policy </misc/api-stability>` policy.
  51
+However, as with previous releases, Django 1.5 ships with some minor
  52
+`backwards incompatible changes`_; people upgrading from previous versions
  53
+of Django should read that list carefully.
  54
+
  55
+One deprecated feature worth noting is the shift to "new-style" :ttag:`url` tag.
  56
+Prior to Django 1.3, syntax like ``{% url myview %}`` was interpreted
  57
+incorrectly (Django considered ``"myview"`` to be a literal name of a view, not
  58
+a template variable named ``myview``). Django 1.3 and above introduced the
  59
+``{% load url from future %}`` syntax to bring in the corrected behavior where
  60
+``myview`` was seen as a variable.
  61
+
  62
+The upshot of this is that if you are not using ``{% load url from future %}``
  63
+in your templates, you'll need to change tags like ``{% url myview %}`` to
  64
+``{% url "myview" %}``. If you *were* using ``{% load url from future %}`` you
  65
+can simply remove that line under Django 1.5
  66
+
16 67
 Python compatibility
17 68
 ====================
18 69
 
19  
-Django 1.5 has dropped support for Python 2.5. Python 2.6.5 is now the minimum
20  
-required Python version. Django is tested and supported on Python 2.6 and
21  
-2.7.
  70
+Django 1.5 requires Python 2.6.5 or above, though we **highly recommended**
  71
+Python 2.7.3 or above. Support for Python 2.5 and below as been dropped.
22 72
 
23 73
 This change should affect only a small number of Django users, as most
24 74
 operating-system vendors today are shipping Python 2.6 or newer as their default
25 75
 version. If you're still using Python 2.5, however, you'll need to stick to
26  
-Django 1.4 until you can upgrade your Python version. Per :doc:`our support policy
27  
-</internals/release-process>`, Django 1.4 will continue to receive security
28  
-support until the release of Django 1.6.
29  
-
30  
-Django 1.5 does not run on a Jython final release, because Jython's latest release
31  
-doesn't currently support Python 2.6. However, Jython currently does offer an alpha
32  
-release featuring 2.7 support.
  76
+Django 1.4 until you can upgrade your Python version. Per :doc:`our support
  77
+policy </internals/release-process>`, Django 1.4 will continue to receive
  78
+security support until the release of Django 1.6.
  79
+
  80
+Django 1.5 does not run on a Jython final release, because Jython's latest
  81
+release doesn't currently support Python 2.6. However, Jython currently does
  82
+offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha
  83
+release.
  84
+
  85
+Python 3 support
  86
+~~~~~~~~~~~~~~~~
  87
+
  88
+Django 1.5 introduces support for Python 3 - specifically, Python
  89
+3.2 and above. This comes in the form of a **single** codebase; you don't
  90
+need to install a different version of Django on Python 3. This means that
  91
+you can write application targeted for just Python 2, just Python 3, or single
  92
+applications that support both platforms.
  93
+
  94
+However, we're labeling this support "experimental" for now: although it's
  95
+receved extensive testing via our automated test suite, it's recieved very
  96
+little real-world testing. We've done our best to eliminate bugs, but we can't
  97
+be sure we covered all possible uses of Django. Further, Django's more than a
  98
+web framework; it's an ecosystem of pluggable components. At this point, very
  99
+few third-party applications have been ported to Python 3, so it's unliukely
  100
+that a real-world application will have all its dependecies satisfied under
  101
+Python 3.
  102
+
  103
+Thus, we're recommending that Django 1.5 not be used in production under Python
  104
+3. Instead, use this oportunity to begin :doc:`porting applications to Python 3
  105
+<topics/python>`. If you're an author of a pluggable component, we encourage you
  106
+to start porting now.
  107
+
  108
+We plan to offer first-class, production-ready support for Python 3 in our next
  109
+release, Django 1.6.
33 110
 
34 111
 What's new in Django 1.5
35 112
 ========================
1  docs/releases/index.txt
@@ -92,6 +92,7 @@ notes.
92 92
 .. toctree::
93 93
    :maxdepth: 1
94 94
 
  95
+   1.5-alpha-1
95 96
    1.4-beta-1
96 97
    1.4-alpha-1
97 98
    1.3-beta-1

0 notes on commit 137fdbe

Please sign in to comment.
Something went wrong with that request. Please try again.