Upgrading Django to a newer version

While it can be a complex process at times, upgrading to the latest Django version has several benefits:

• New features and improvements are added.
• Bugs are fixed.
• Older version of Django will eventually no longer receive security updates. (see Supported versions).
• Upgrading as each new Django release is available makes future upgrades less painful by keeping your code base up to date.

Here are some things to consider to help make your upgrade process as smooth as possible.

Required Reading

If it’s your first time doing an upgrade, it is useful to read the guide on the different release processes.

Afterwards, you should familiarize yourself with the changes that were made in the new Django version(s):

• Read the release notes for each ‘final’ release from the one after your current Django version, up to and including the version to which you plan to upgrade.
• Look at the deprecation timeline for the relevant versions.

Pay particular attention to backwards incompatible changes to get a clear idea of what will be needed for a successful upgrade.

Dependencies

In most cases it will be necessary to upgrade to the latest version of your Django-related dependencies as well. If the Django version was recently released or if some of your dependencies are not well-maintained, some of your dependencies may not yet support the new Django version. In these cases you may have to wait until new versions of your dependencies are released.

Resolving deprecation warnings

Before upgrading, it’s a good idea to resolve any deprecation warnings raised by your project while using your current version of Django. Fixing these warnings before upgrading ensures that you’re informed about areas of the code that need altering.

In Python, deprecation warnings are silenced by default. You must turn them on using the -Wall Python command line option or the PYTHONWARNINGS environment variable. For example, to show warnings while running tests:

$ python -Wall manage.py test

If you’re not using the Django test runner, you may need to also ensure that any console output is not captured which would hide deprecation warnings. For example, if you use py.test:

$ PYTHONWARNINGS=all py.test tests --capture=no

Resolve any deprecation warnings with your current version of Django before continuing the upgrade process.

Third party applications might use deprecated APIs in order to support multiple versions of Django, so deprecation warnings in packages you’ve installed don’t necessarily indicate a problem. If a package doesn’t support the latest version of Django, consider raising an issue or sending a pull request for it.

Installation

Once you’re ready, it is time to install the new Django version. If you are using virtualenv and it is a major upgrade, you might want to set up a new environment with all the dependencies first.

Exactly which steps you will need to take depends on your installation process. The most convenient way is to use pip with the --upgrade or -U flag:

$ pip install -U Django

pip also automatically uninstalls the previous version of Django.

If you use some other installation process, you might have to manually uninstall the old Django version and should look at the complete installation instructions.

Testing

When the new environment is set up, run the full test suite for your application. Again, it’s useful to turn on deprecation warnings on so they’re shown in the test output (you can also use the flag if you test your app manually using manage.py runserver):

$ python -Wall manage.py test

After you have run the tests, fix any failures. While you have the release notes fresh in your mind, it may also be a good time to take advantage of new features in Django by refactoring your code to eliminate any deprecation warnings.

Deployment

When you are sufficiently confident your app works with the new version of Django, you’re ready to go ahead and deploy your upgraded Django project.

If you are using caching provided by Django, you should consider clearing your cache after upgrading. Otherwise you may run into problems, for example, if you are caching pickled objects as these objects are not guaranteed to be pickle-compatible across Django versions. A past instance of incompatibility was caching pickled HttpResponse objects, either directly or indirectly via the cache_page() decorator.