merge requestresponse section into various changes subsections

1 files changed, 39 insertions, 33 deletions

diff --git a/CHANGES.txt b/CHANGES.txt
index 83d71e2b7..5f450fdcd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,39 +1,6 @@
 Next release
 ============
 
-Requestresponse branch
-----------------------
-
-- Deprecated all assignments to ``request.response_*`` attributes (for
-  example ``request.response_content_type = 'foo'`` is now deprecated).
-  Assignments and mutations of the following assignable request attributes
-  that were considered by the framework for response influence are now
-  deprecated: ``response_content_type``, ``response_headerlist``,
-  ``response_status``, ``response_charset``, and ``response_cache_for``.
-  Instead of assigning these to the request object for later detection by the
-  rendering machinery, users should use the appropriate API of the Response
-  object created by accessing ``request.response`` (e.g. code which does
-  ``request.response_content_type = 'abc'`` should be changed to
-  ``request.response.content_type = 'abc'``).
-
-- A custom request factory is now required to return a response object that
-  has a ``response`` attribute (or "reified"/lazy property) if they the
-  request is meant to be used in a view that uses a renderer.  This
-  ``response`` attribute should be an instance of the class
-  ``pyramid.response.Response``.
-
-- The JSON and string renderer factories now assign to
-  ``request.response.content_type`` rather than
-  ``request.response_content_type``.  Each renderer factory adetermines
-  whether it should change the content type of the response by comparing the
-  response's content type against the response's default content type; if the
-  content type is not the default content type (usually ``text/html``), the
-  renderer changes the content type (to ``application/json`` or
-  ``text/plain`` for JSON and string renderers respectively).
-
-- Made it possible to assign to and delete
-  ``pyramid.testing.DummyRequest.registry`` (bugfix).
-
 Documentation
 -------------
 
@@ -61,6 +28,12 @@ Documentation
 Features
 --------
 
+- Accessing the ``response`` attribute of a ``pyramid.request.Request``
+  object (e.g. ``request.response`` within a view) now produces a new
+  ``pyramid.response.Response`` object.  This feature is meant to be used
+  mainly when a view configured with a renderer needs to set response
+  attributes, but it can be used by any code.
+
 - Integers and longs passed as ``elements`` to ``pyramid.url.resource_url``
   or ``pyramid.request.Request.resource_url`` e.g. ``resource_url(context,
   request, 1, 2)`` (``1`` and ``2`` are the ``elements``) will now be
@@ -147,6 +120,39 @@ Bug Fixes
 - Redirects issued by a static view did not take into account any existing
   ``SCRIPT_NAME`` (such as one set by a url mapping composite).  Now they do.
 
+Deprecations
+------------
+
+- Deprecated all assignments to ``request.response_*`` attributes (for
+  example ``request.response_content_type = 'foo'`` is now deprecated).
+  Assignments and mutations of assignable request attributes that were
+  considered by the framework for response influence are now deprecated:
+  ``response_content_type``, ``response_headerlist``, ``response_status``,
+  ``response_charset``, and ``response_cache_for``.  Instead of assigning
+  these to the request object for later detection by the rendering machinery,
+  users should use the appropriate API of the Response object created by
+  accessing ``request.response`` (e.g. code which does
+  ``request.response_content_type = 'abc'`` should be changed to
+  ``request.response.content_type = 'abc'``).
+
+Behavior Changes
+----------------
+
+- A custom request factory is now required to return a response object that
+  has a ``response`` attribute (or "reified"/lazy property) if they the
+  request is meant to be used in a view that uses a renderer.  This
+  ``response`` attribute should be an instance of the class
+  ``pyramid.response.Response``.
+
+- The JSON and string renderer factories now assign to
+  ``request.response.content_type`` rather than
+  ``request.response_content_type``.  Each renderer factory determines
+  whether it should change the content type of the response by comparing the
+  response's content type against the response's default content type; if the
+  content type is not the default content type (usually ``text/html``), the
+  renderer changes the content type (to ``application/json`` or
+  ``text/plain`` for JSON and string renderers respectively).
+
 Dependencies
 ------------