You might have additional packages that you use in your project like Django Rest Framework or some packages to use AWS or Google Cloud APIs that also need to be specified in your requirements.in file, but that list of packages should be significantly smaller that the full list of versioned requirements that pip-compile will generate and save to requirements.txt.
When upgrading to Django 2.0, you only have to update the requirement to Django<2.1. pip-compile will use this requirement to compile a requirements.txt file with specific versions for Django and all the dependent packages in turn. When using pip-compile, simply specify the version requirement for Django itself in requirements.in (e.g, for Django 1.11 this would be Django<2.0).
When you install a particular version of Django, let's say Django 1.11, pip will install a whole bunch of dependencies along with it. Rather than updating the version of each package individually, you can use the pip-compile command to compile a requirements.txt file for you from an existing setup.py or a requirements.in file. Or perhaps not! If you are still stuck on version 1.7, chances are that you are not using something like pip-tools to generate the requirements.txt file for you. Once you have reviewed the release notes of the version, fixed all deprecation warnings and updated test coverage, it is time to update the version of Django in your requirements.txt.
In fact, in the absence of unit tests, do not upgrade! It would be wiser to delay the upgrade and add enough unit tests to cover at least 50% of the project.
In the absence of unit tests, you only have time-consuming manual testing to exercise the code. Unit tests are vital when attempting upgrades of any nature. Please add '.SessionAuthenticationMiddleware' to your MIDDLEWARE_CLASSES setting when you are ready to opt-in after reading the upgrade considerations in the 1.8 release notes. RemovedInDjango110Warning: Session verification will become mandatory in Django 1.10. Usually, the deprecation warnings are very explicit and most helpful. Django will show deprecation warnings when you run tests with Make sure that you have addressed all deprecation warnings before upgrading to the next version. If you go to the Django deprecation timeline, you can see all deprecations going back all the way to version 1.7.
The release notes for Django 1.8 can be found here.īackwards incompatible changes and deprecations are of particular importance when reviewing the release notes. Release notes for older versions are not where you might expect them to be, so you might only find them by searching for “Django 1.8 release notes” or looking through the docs.
Read the Release Notesīefore you attempt an upgrade of a particular Django version, it is prudent to review the release notes for the version that you are upgrading to. However, Django 1.11 was already compatible with Python 3, so in the divide-and-conquer spirit, you should attempt the upgrade to Python 3 right after you migrated to Django 1.11. Practically speaking, that means upgrade from 1.7 to 1.8, 1.8 to 1.9, 1.9 to 1.10, etc., until you reach your destination.Īs far as upgrading Python is concerned, know that Django 1.11 was the last to support Python 2.7. Faced with such a massive multi-version upgrade, the best advice we can give you is to divide and conquer. Besides having to deal with the upgrade of Django itself, you shouldn't forget that an upgrade like this implies an upgrade from Python 2 to 3 as well.Īlthough somebody is likely bold enough to try and upgrade directly from Django 1.7 to 3.2, it isn't what our team would recommend, and we're confident very few experienced Django developers will encourage a direct upgrade. In fact, one might call it a monster of a job. Migrating from Django 1.7 to 3.1 is no small task.