.. _releases-1.2-beta-1:

===============================

Django 1.2 beta 1 release notes

===============================

February 5, 2010

Welcome to Django 1.2 beta 1!

This is the second in a series of preview/development releases leading

up to the eventual release of Django 1.2, currently scheduled to take

place in March 2010. This release is primarily targeted at developers

who are interested in trying out new features and testing the Django

codebase to help identify and resolve bugs prior to the final 1.2

release.

As such, this release is *not* intended for production use, and any

such use is discouraged.

This document covers changes since the Django 1.2 alpha release; the

:ref:`1.2 alpha release notes <releases-1.2-alpha-1>` cover new and

updated features in Django between 1.1 and 1.2 alpha.

What's new in 1.2 beta

======================

This 1.2 beta release marks the final feature freeze for Django 1.2;

while most feature development was completed for 1.2 alpha (which

constituted a freeze on major features), a few other new features were

added afterward and so are new as of 1.2 beta.

Additionally, some existing APIs have been deprecated; under `our API

stability policy <misc-api-stability>`, these APIs will continue to

work for now, but will raise ``PendingDeprecationWarning`` in Django

1.2 and ``DeprecationWarning`` in Django 1.3, before being removed in

Django 1.4.

Class-based test runners

------------------------

Django 1.2 changes the test runner tools to use a class-based

approach. Old style function-based test runners will still work, but

should be updated to use the new :ref:`class-based runners

<topics-testing-test_runner>`.

``Feed`` in ``django.contrib.syndication.feeds``

------------------------------------------------

The :class:`django.contrib.syndication.feeds.Feed` class is being

replaced by the :class:`django.contrib.syndication.views.Feed` class.

The old ``feeds.Feed`` class is deprecated, and will be removed in

Django 1.4.

The new class has an almost identical API, but allows instances to be

used as views. For example, consider the use of the old framework in

the following :ref:`URLconf <topics-http-urls>`::

from django.conf.urls.defaults import *

from myproject.feeds import LatestEntries, LatestEntriesByCategory

feeds = {

'latest': LatestEntries,

'categories': LatestEntriesByCategory,

}

urlpatterns = patterns('',

# ...

(r'^feeds/(?P<url>.*)/$', 'django.contrib.syndication.views.feed',

{'feed_dict': feeds}),

# ...

)

Using the new Feed class, these feeds can be deployed directly as views::

from django.conf.urls.defaults import *

from myproject.feeds import LatestEntries, LatestEntriesByCategory

urlpatterns = patterns('',

# ...

(r'^feeds/latest/$', LatestEntries()),

(r'^feeds/categories/(?P<category_id>\d+)/$', LatestEntriesByCategory()),

# ...

)

If you currently use the ``feed()`` view, the ``LatestEntries`` class

would not need to be modified apart from subclassing the new

:class:`~django.contrib.syndication.views.Feed` class.

However, ``LatestEntriesByCategory`` uses the ``get_object()`` method

with the ``bits`` argument to specify a specific category to show. In

the new :class:`~django.contrib.syndication.views.Feed` class,

``get_object()`` method takes a ``request`` and arguments from the

URL, so it would look like this::

from django.contrib.syndication.views import Feed

from django.shortcuts import get_object_or_404

from myproject.models import Category

class LatestEntriesByCategory(Feed):

def get_object(self, request, category_id):

return get_object_or_404(Category, id=category_id)

# ...

Additionally, the ``get_feed()`` method on ``Feed`` classes now take

different arguments, which may impact you if you use the ``Feed``

classes directly. Instead of just taking an optional ``url`` argument,

it now takes two arguments: the object returned by its own

``get_object()`` method, and the current ``request`` object.

To take into account ``Feed`` classes not being initialized for each

request, the ``__init__()`` method now takes no arguments by default.

Previously it would have taken the ``slug`` from the URL and the

``request`` object.

In accordance with `RSS best practices`_, RSS feeds will now include

an ``atom:link`` element. You may need to update your tests to take

this into account.

For more information, see the full :ref:`syndication framework

documentation <ref-contrib-syndication>`.

.. _RSS best practices: http://www.rssboard.org/rss-profile

Cookie encoding

---------------

Due to cookie-handling bugs in Internet Explorer, Safari, and possibly

other browsers, our encoding of cookie values was changed so that the

characters comma (',') and semi-colon (';') are treated as non-safe

characters, and are therefore encoded as ``\054`` and ``\073``

respectively. This could produce backwards incompatibilities if you

are relying on the ability to set these characters directly in cookie

values.

Object-level permissions

------------------------

A foundation for specifying permissions at the per-object level has

been added. The default authentication backends shipped with Django do

not make use of this, but third-party authentication backends are free

to do so. See the :ref:`authentication docs <topics-auth>` for more

information.

Permissions for anonymous users

-------------------------------

If you provide a custom authentication backend with the attribute

``supports_anonymous_user`` set to ``True``, the ``AnonymousUser``

class will check the backend for permissions, just as the normal

``User`` does. This is intended to help centralize permission

handling; apps can always delegate the question of whether something

is allowed or not to the authorization/authentication system. See the

:ref:`authentication docs <topics-auth>` for more details.

The Django 1.2 roadmap

======================

Before the final Django 1.2 release, at least one additional

preview/development releases will be made available. The current

schedule consists of at least the following:

* Week of **March 2, 2010**: First Django 1.2 release

candidate. String freeze for translations.

* Week of **March 9, 2010**: Django 1.2 final release.

If necessary, additional beta or release-candidate packages will be

issued prior to the final 1.2 release. Django 1.2 will be released

approximately one week after the final release candidate.

What you can do to help

=======================

In order to provide a high-quality 1.2 release, we need your

help. Although this beta release is, again, *not* intended for

production use, you can help the Django team by trying out the beta

codebase in a safe test environment and reporting any bugs or issues

you encounter. The Django ticket tracker is the central place to

search for open issues:

* http://code.djangoproject.com/timeline

Please open new tickets if no existing ticket corresponds to a problem

you're running into.

Additionally, discussion of Django development, including progress

toward the 1.2 release, takes place daily on the django-developers

mailing list:

* http://groups.google.com/group/django-developers

... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If

... you're

interested in helping out with Django's development, feel free to join the

discussions there.

Django's online documentation also includes pointers on how to

contribute to Django:

* :ref:`How to contribute to Django <internals-contributing>`

Contributions on any level -- developing code, writing documentation

or simply triaging tickets and helping to test proposed bugfixes --

are always welcome and appreciated.

Development sprints for Django 1.2 will also be taking place at PyCon

US 2010, on the dedicated sprint days (February 22 through 25), and

anyone who wants to help out is welcome to join in, either in person

at PyCon or virtually in the IRC channel or on the mailing list.