Frequently Asked Questions
Common questions about upgrading Django projects and sites
- Is upgrading Django hard?
- Django is relatively easy to upgrade. There is a particular emphasis on backwards compatability. Often you only have to make a few changes to how you're using Django itself between each minor release.
- What's the hardest part of upgrading Django?
- You will spend the majority of your time upgrading the third party Django apps you are using. Third party apps typically use deeper aspects of Django's APIs that may have changed since you installed the app. Looking at the release notes for your third party dependencies is often the best way to determine what you need to update and to which version.
- What does Django LTS really mean?
- LTS stands for Long Term Support. It means the Django community has agreed to support this version with security and bug fixes for a period of 3 years after its initial release.
- Do I really need to upgrade?
- Yes, if you value security and safety in your Django site. Patch releases are trivial to upgrade almost never requiring changes to your code or dependencies.
- What is the difference between major, minor and patch releases?
- If we use the version X.Y.Z as an example. The Z denotes patch. Y, a minor release. And X, a major release. Patches are small security or bug fixes that should not require any changes on your part. Minor releases add new features and change existing features enough that you will likely need to adjust your code and dependencies a bit. Major releases are just that, major. You will almost certainly have to adjust your code and dependencies.
- Which version of Django is async?
- Async views and middleware were introduced in version 3.1. Django 4.0 added async for the cache system. Initial support for asynchronous ORM support was added in Django 4.1.
- Which version of Django was the last to support Python 2?
- Django 1.11 was the last version of Django to support Python 2. However, support for that version ended December 1st, 2017.
- What's the recommended upgrade path for very old Django projects?
- For projects on very old Django versions (1.x or early 2.x), it's best to upgrade incrementally through each major version rather than attempting to jump directly to the latest. Start by upgrading to the latest patch release of your current major version, then move to the next major version. For instance, if you're on Django 1.8, upgrade to 1.11 (last 1.x LTS), then 2.2 (LTS), then 3.2 (LTS), and so on.
- How do I handle deprecated features during an upgrade?
-
Django's deprecation policy is very clear: features marked as deprecated in version X will be removed in version X+2. When upgrading, check the deprecation warnings in your test suite and update your code to use recommended alternatives. Running your tests with the
python -Waflag will display deprecation warnings that would normally be hidden. - Should I upgrade Django before or after upgrading Python?
- It's generally easier to upgrade Django first while staying on your current Python version, then upgrade Python afterward. Check Django's documentation for the Python versions supported by each Django release to ensure compatibility before upgrading either component.
- How do I test my Django upgrade before deploying to production?
- Create a separate branch for the upgrade, update your requirements, run your test suite, and fix any issues. Set up a staging environment that mirrors production as closely as possible, deploy your upgraded code there, and thoroughly test all features. Consider enabling Django's deprecation warnings during this phase to catch any potential future issues.