Last week Django 1.6 was released. Feature wise, this was mostly minor release. The three big features are:

1. Simplified default project and application templates

2. A new transaction handling system

3. Persistent database connections

These are all fairly minor improvements to what the recent 1.4 and 1.5 versions offered. By comparison 1.4 and 1.5 offered more revolutionary features such as a customizable User model, Python 3 support, prefetch_related, support for streaming responses, a completely revamped and clearer project structure. Even the more minor 1.5 changes such as timezone handling and bulk_create are larger than the 1.6 changes. With the frequency of recent releases though, it is almost refreshing to see a release that is a bit tamer.

The last few releases have all been nearly mandatory (if you haven’t upgraded to 1.5 yet you should seriously consider it. Seriously, stop reading and go do it.) Between 1.3 and 1.5 Django introduced massive improvements that drastically impact day to day usage such as prefetch_related, massively improved timezone handling, a massive overhaul to the project/application structure that make it significantly more intuitive, class based views, logging support, and django-staticfiles rolled into core.

Django is exceptionally stable overall and with the great features released in the last few versions it would have been silly to start a project on anything other than the latest version. Although upgrading to 1.3 or less can be fairly challenging for old projects, the benefit from the new tools and opportunities offered by in 1.4 and beyond should outweigh the temporary pain of upgrading. Recent Django releases have come quickly and contained major changes (thanks in large part to a major expansion of the Django core team.) With the major tasks that were accomplished in the last few release, 1.6 is a bit less revolutionary and more incremental. Hopefully this is a sign of Django maturing and stabilizing long term.

Hopefully this is a sign of Django maturing and stabilizing long term.

The upgrade path to 1.6 from 1.5 is very straightforward and few installations should see any issues with upgrading. The new transaction API is the highest impact change, but the old transaction API is still in place for now so existing projects should see little impact. They also added a new test runner that has some quirks such as not finding tests in or locate doctests automatically, both of those cases are pretty rare though and easily fixed. There are some other minor backwards incompatible changes that you may want to be aware of that you can see from the release notes. If you are still on < 1.4 the upgrade path is a good bit trickier due to the new project layout, but the benefits are significantly more impressive as well. As such if you are on < 1.4 you should strongly consider bringing your project up to date, despite the pain.

All in all, 1.6 doesn’t offer much in the way of enticements to upgrade existing projects, but a nice set of incremental changes. Any new projects should be started on Django 1.6, despite the minimal feature changes. Django’s history of stable releases should give you the confidence to choose the newest version whenever you start a project even if it was recently released; just watch for any security or bug patches for the next couple months released as a minor version. If you haven’t made the leap to at least 1.5 yet, you’re missing out and should choose 1.6 when you upgrade. However, if you’re already on 1.5 the benefits are pretty minimal to upgrading to 1.6 and unless there is a minor feature critical to your application you likely be just as happy holding off for 1.7 to upgrade. 1.7 should be considered nearly mandatory once it’s released as migrations are finally being brought into core!

Any new projects should be started on Django 1.6, despite the minimal feature changes.