The Django Book 2 教程所用的Django版本比1.2要小，所以高版本的部分特性可能没有，下面是1.2版本Django的Change log
——————————————-
经过将近一年的开发，Django 1.2 加入了让人振奋的新特征和修正了大量的Bug,以下文档将有助你了解Django 1.2和从老版本升级到Django 1.2注意事项。
概述：
Django 1.2引入了几个大的重要的特性，它们包括：
-单个实例中多个数据库的支持
-类似于Form验证的Model验证
-增强型的跨域请求保护 CSRF框架
-一个全新的基于cookie和session的不受限于匿名用户的用户消息框架
-对象级别的权限，匿名用户权限和更灵活的用户名字符
-可自定义的邮件发送后端
-新的轻量级的if 模板标签
以上这些都是大概的列举，详情参考以下页面。
兼容性的大概说明：
-Django 1.2不再支持宿主言语Python2.3. 请参考整个文档说明
-全新跨域请求保护框架不兼容老版本，但不影响老版本的使用，直到Django1.4，升级到全新的框架，请务必了解一下 详情
-自定义的子类字段，有几个方法发生改变了，详情参考get_db_prep_*()系列方法
-一些内置的模板标签有了变化；自定义模板标签需要存储状态了，新的规则参考 stateful template tags
-需要修饰器中user_passes_test,login_required和permission_requiredmethod的话，需要多套用一个method_decorator，参考详情
以上这些同样是重点的向后兼容的大概列举，老版本升级的时候强烈推荐阅读以下 backwards-incompatible changes 和 the list of deprecated features文档。
Django 1.2 对Python版本的兼容性
目前为止，我们严格在Python2.4 2.5 2.6 和2.7上良好运行，并做到了对这几个版本的兼容，但对python2.3和以下版本不再做到兼容，这些变化只是对少数人产生影响，因为很多服务器提供商都采用了2.4或以上的python版本了，如果你想在python2.3环境中使用Django的话，请使用Django1.1.1或之前的版本。
未来Django的兼容性，会慢慢过渡到Python3系列。
Django 1.2 的新特性（参考了JAY的原文）

-支持指定多个数据库。
Django 1.2 项目项目中终于可以使用多个数据库了。查询可以通过using方法查询制定的数据库，保存数据的时候同样可以在save方法中指定参数，保存到指定的数据库。
-开发人员受Form validation的启发，也给model加上了validation验证。

-增强对CSRF攻击的防护功能。
Django1.2现在大大增强了跨域请求攻击的保护，安全性有了很大的提高。
-新增加了一个强大可配置的消息框架。
全新的消息框架功能很强大，可配置性灵活，以前只是认证用户能使用消息框架，现在匿名用户也可以使用它了。全新消息框架基于cookie和session。很实用的东西。
-可以在对象级别定义权限
每个对象级的权限功能被添加到原先的权限模块中。虽然没有在Django核心中加入，但你可以在自定义验证后端中使用它，django.contrib.auth.models.User 就用到了它，有关用户验证更多信息 。

-可以为匿名用户提供权限

-内建的User现在对用户名的限制更为宽松
内建的用户实体的用户名现在更为宽松，在原来的基础上追加字符：@，+，- 字符。而且username可以为中文。
-需要自定义email发送的童鞋可以看看新加的Email Backend
-智能的增强版if标签
{% ifnotequal a b %}
…
{% endifnotequal %}
现在可以:
{% if a != b %}
…
{% endif %}
万不得已时，尽量少使用{% ifnotequal %} {% ifequal %}吧。if标签的操作符有：==， ！=，<，>，<=，>=，in 和not in，而且and or not已经得到很好的支持了，超酷。
-模板缓存
在先前Django的版本中，每次你渲染模板的时候都需要在硬盘中重新加载，而现在的Django1.2，你可以使用cachedtemplate loader 装载模板，在每次渲染页面的时候，就直接在缓存里取模板了。因此渲染页面有了质的飞跃，特别对有大量的零碎模板的情况（比如使用 {%extends%}和{%include%}标签）更有利。
-Fixture里面如今支持Natural Key，这使得fixture可读性大大上升。
-测试新增–fastfail参数，在遇到错误时直接退出，而不进行后面的测试。
-Model现在支持64位整型字段——BigIntegerField。
-增强多语言处理，如今在处理时间和form的时候会参考当前的locale进行本地化。
-ModelAdmin开始支持readonly_fields。
-django-admin.py/manage.py可以从DJANGO_COLORS环境变量里读取高亮设置，在支持ASCII色彩的终端里面输出装b的彩色文字
-Syndication可以直接作为view在URLconf里面使用。
-GeoDjango增加了一些新功能。
-admin中的inline操作使用了js进行了增强，UE更酷更爽更舒服。
如果用户在浏览器中启用了JavaScript，Admin后台允许动态添加和删除inline实体；如果浏览器某开启JavaScript，inline实体的操作上没有改变。
-模板标签now新增两个格式化字符：c和u。
模板中新增的格式化字符 c输出ISO 8601格式的字符，u输出带微秒的时间字符。
——————————————-
下面 历史的Change log
What’s new in Django 1.3:
March 23rd, 2011

· A framework for writing class-based views.
· Built-in support for using Python’s logging facilities.
· Contrib support for easy handling of static files.
· Django’s testing framework now supports (and ships with a copy of) the unittest2 library.

What’s new in Django 1.2.5:
February 9th, 2011

Backwards incompatible changes:
· FileField no longer deletes files
· Use of custom SQL to load initial data in tests
· ModelAdmin.lookup_allowed signature changed

What’s new in Django 1.1.2:
May 14th, 2010

Test runner exit status code:
· The exit status code of the test runners (tests/runtests.py and python manage.py test) no longer represents the number of failed tests, since a failure of 256 or more tests resulted in a wrong exit status code. The exit status code for the test runner is now 0 for success (no failing tests) and 1 for any number of test failures. If needed, the number of test failures can be found at the end of the test runner’s output.

Cookie encoding:
· To fix bugs with cookies 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 54 and 73 respectively. This could produce backwards incompatibilities, especially if you are storing comma or semi-colon in cookies and have javascript code that parses and manipulates cookie values client-side.

One new feature:
· Ordinarily, a point release would not include new features, but in the case of Django 1.1.2, we have made an exception to this rule. Django 1.2 (the next major release of Django) will contain a feature that will improve protection against Cross-Site Request Forgery (CSRF) attacks. This feature requires the use of a new csrf_token template tag in all forms that Django renders.
· To make it easier to support both 1.1.X and 1.2.X versions of Django with the same templates, we have decided to introduce the csrf_token template tag to the 1.1.X branch. In the 1.1.X branch, csrf_token does nothing – it has no effect on templates or form processing. However, it means that the same template will work with Django 1.2.

What’s new in Django 1.2 Beta 1:
March 9th, 2010

· CsrfResponseMiddleware and CsrfMiddleware have been deprecated and will be removed completely in Django 1.4, in favor of a template tag that should be inserted into forms.
· All contrib apps use a csrf_protect decorator to protect the view. This requires the use of the csrf_token template tag in the template. If you have used custom templates for contrib views, you MUST READ THE UPGRADE INSTRUCTIONS to fix those templates.
· CsrfViewMiddleware is included in MIDDLEWARE_CLASSES by default. This turns on CSRF protection by default, so views that accept POST requests need to be written to work with the middleware. Instructions on how to do this are found in the CSRF docs.
· All of the CSRF has moved from contrib to core (with backwards compatible imports in the old locations, which are deprecated).

What’s new in Django 1.1:
August 11th, 2009

ORM improvements:
· Two major enhancements have been added to Django’s object-relational mapper (ORM): aggregate support, and query expressions.

Aggregate support:
· It’s now possible to run SQL aggregate queries (i.e. COUNT(), MAX(), MIN(), etc.) from within Django’s ORM. You can choose to either return the results of the aggregate directly, or else annotate the objects in a QuerySet with the results of the aggregate query.
· This feature is available as new QuerySet.aggregate()`() and QuerySet.annotate()`() methods, and is covered in detail in the ORM aggregation documentation.

Query expressions:
· Queries can now refer to a another field on the query and can traverse relationships to refer to fields on related models. This is implemented in the new F object; for full details, including examples, consult the documentation for F expressions.

Model improvements:
“Unmanaged” models:
· You can now control whether or not Django manages the life-cycle of the database tables for a model using the managed model option. This defaults to True, meaning that Django will create the appropriate database tables in syncdb and remove them as part of the reset command. That is, Django manages the database table’s lifecycle.
· If you set this to False, however, no database table creating or deletion will be automatically performed for this model. This is useful if the model represents an existing table or a database view that has been created by some other means.

Proxy models:
· You can now create proxy models: subclasses of existing models that only add Python-level (rather than database-level) behavior and aren’t represented by a new table. That is, the new model is a proxy for some underlying model, which stores all the real data.
· All the details can be found in the proxy models documentation. This feature is similar on the surface to unmanaged models, so the documentation has an explanation of how proxy models differ from unmanaged models.

Deferred fields:
· In some complex situations, your models might contain fields which could contain a lot of data (for example, large text fields), or require expensive processing to convert them to Python objects. If you know you don’t need those particular fields, you can now tell Django not to retrieve them from the database.
· You’ll do this with the new queryset methods defer() and only().

Testing improvements:
· A few notable improvements have been made to the testing framework.

Test performance improvements:
· Tests written using Django’s testing framework now run dramatically faster (as much as 10 times faster in many cases).
· This was accomplished through the introduction of transaction-based tests: when using django.test.TestCase, your tests will now be run in a transaction which is rolled back when finished, instead of by flushing and re-populating the database. This results in an immense speedup for most types of unit tests. See the documentation for TestCase and TransactionTestCase for a full description, and some important notes on database support.

Test client improvements:
A couple of small — but highly useful — improvements have been made to the test client:
· The test Client now can automatically follow redirects with the follow argument to Client.get() and Client.post(). This makes testing views that issue redirects simpler.
· It’s now easier to get at the template context in the response returned the test client: you’ll simply access the context as request.context[key]. The old way, which treats request.context as a list of contexts, one for each rendered template in the inheritance chain, is still available if you need it.

New admin features:
Editable fields on the change list¶:
· You can now make fields editable on the admin list views via the new list_editable admin option. These fields will show up as form widgets on the list pages, and can be edited and saved in bulk.

Admin “actions”:
· You can now define admin actions that can perform some action to a group of models in bulk. Users will be able to select objects on the change list page and then apply these bulk actions to all selected objects.
· Django ships with one pre-defined admin action to delete a group of objects in one fell swoop.

Conditional view processing:
· Django now has much better support for conditional view processing using the standard ETag and Last-Modified HTTP headers. This means you can now easily short-circuit view processing by testing less-expensive conditions. For many views this can lead to a serious improvement in speed and reduction in bandwidth.

URL namespaces:
· Django 1.1 improves named URL patterns with the introduction of URL “namespaces.”
· In short, this feature allows the same group of URLs, from the same application, to be included in a Django URLConf multiple times, with varying (and potentially nested) named prefixes which will be used when performing reverse resolution. In other words, reusable applications like Django’s admin interface may be registered multiple times without URL conflicts.

Other new features and changes introduced since Django 1.0 include:
· The CSRF protection middleware has been split into two classes — CsrfViewMiddleware checks incoming requests, and CsrfResponseMiddleware processes outgoing responses. The combined CsrfMiddleware class (which does both) remains for backwards-compatibility, but using the split classes is now recommended in order to allow fine-grained control of when and where the CSRF processing takes place.
· reverse() and code which uses it (e.g., the {% url %} template tag) now works with URLs in Django’s administrative site, provided that the admin URLs are set up via include(admin.site.urls) (sending admin requests to the admin.site.root view still works, but URLs in the admin will not be “reversible” when configured this way).
· The include() function in Django URLconf modules can now accept sequences of URL patterns (generated by patterns()) in addition to module names.
· Instances of Django forms (see the forms overview now have two additional methods, hidden_fields() and visible_fields(), which return the list of hidden — i.e., — and visible fields on the form, respectively.
· The redirect_to generic view (see the generic views documentation) now accepts an additional keyword argument permanent. If permanent is True, the view will emit an HTTP permanent redirect (status code 301). If False, the view will emit an HTTP temporary redirect (status code 302).
· A new database lookup type — week_day — has been added for DateField and DateTimeField. This type of lookup accepts a number between 1 (Sunday) and 7 (Saturday), and returns objects where the field value matches that day of the week. See the full list of lookup types for details.
· The {% for %} tag in Django’s template language now accepts an optional {% empty %} clause, to be displayed when {% for %} is asked to loop over an empty sequence. See the list of built-in template tags for examples of this.
· The dumpdata management command now accepts individual model names as arguments, allowing you to export the data just from particular models.
· There’s a new safeseq template filter which works just like safe for lists, marking each item in the list as safe.
· Cache backends now support incr() and decr() commands to increment and decrement the value of a cache key. On cache backends that support atomic increment/decrement — most notably, the memcached backend — these operations will be atomic, and quite fast.
· Django now can easily delegate authentication to the web server via a new authentication backend that supports the standard REMOTE_USER environment variable used for this purpose.
· There’s a new django.shortcuts.redirect() function that makes it easier to issue redirects given an object, a view name, or a URL.
· The postgresql_psycopg2 backend now supports native PostgreSQL autocommit. This is an advanced, PostgreSQL-specific feature, that can make certain read-heavy applications a good deal faster.

What’s new in Django 1.0.2:
November 19th, 2008

· The primary reason behind this release is to remedy an issue in the recently-released Django 1.0.1; the packaging scripts used for Django 1.0.1 omitted some directories from the final release package, including one directory required by django.contrib.gis and part of Django’s unit-test suite.
· Django 1.0.2 contains updated packaging scripts, and the release package contains the directories omitted from Django 1.0.1. As such, this release contains all of the fixes and improvements from Django 1.0.1; see the Django 1.0.1 release notes for details.
· Updated Hebrew and Danish translations have been added.
· The default __repr__ method of Django models has been made more robust in the face of bad Unicode data coming from the __unicode__ method; rather than raise an exception in such cases, repr() will now contain the string “[Bad Unicode data]” in place of the invalid Unicode.
· A bug involving the interaction of Django’s SafeUnicode class and the MySQL adapter has been resolved; SafeUnicode instances (generated, for example, by template rendering) can now be assigned to model attributes and saved to MySQL without requiring an explicit intermediate cast to unicode.
· A bug affecting filtering on a nullable DateField in SQLite has been resolved.
· Several updates and improvements have been made to Django’s documentation.

What’s new in Django 1.0.1:
November 15th, 2008

· Several fixes in django.contrib.comments, pertaining to RSS feeds of comments, default ordering of comments and the XHTML and internationalization of the default templates for comments.
· Multiple fixes for Django’s support of Oracle databases, including pagination support for GIS QuerySets, more efficient slicing of results and improved introspection of existing databases.
· Several fixes for query support in the Django object-relational mapper, including repeated setting and resetting of ordering and fixes for working with INSERT-only queries.
· Multiple fixes for inline forms in formsets.
· Multiple fixes for unique and unique_together model constraints in automatically-generated forms.
· Fixed support for custom callable upload_to declarations when handling file uploads through automatically-generated forms.
· Fixed support for sorting an admin change list based on a callable attributes in list_display.
· A fix to the application of autoescaping for literal strings passed to the join template filter. Previously, literal strings passed to join were automatically escaped, contrary to the documented behavior for autoescaping and literal strings. Literal strings passed to join are no longer automatically escaped, meaning you must now manually escape them; this is an incompatibility if you were relying on this bug, but not if you were relying on escaping behaving as documented.
· Improved and expanded translation files for many of the languages Django supports by default.
· And as always, a large number of improvements to Django’s documentation, including both corrections to existing documents and expanded and new documentation.