One of the first things you need to do when starting a new Django project is to choose which version of Django you are going to use. At any given time, there could be as many as three supported Django versions available to choose from:
- previous long-term supported version (LTS)
- current LTS
- latest official version
I’m excluding pre-releases from this list which should only be used for testing.
What are you optimizing for?
The first question to ask yourself is what are you optimizing for. When we are building applications for our clients we are almost always optimizing to reduce costs, both during the initial development process and in support post-launch. For this reason, we are choosing versions which meet the goals of maximimizing interoperability with the Django ecosystem and minimizing maintenance (aka toil) down-the-road. Unless you are working on a hobby project and want to play with new features, I’d argue these goals are universal.
Notes on Django Versioning
Django does not follow the semantic versioning standard strictly. Versions will always be made up of three numbers (major.minor.patch). Minor version 2 is always an LTS version. After the LTS, the major version is incremented and two minor releases are made on it (x.0 and x.1). Patch versions are released for bugs found on any supported versions. For more info, see DEP-0004.
Check Supported Versions to see the current LTS cycle. As of June, 2022 it looks like this,
Minimizing Maintenance
The best way to minimize future maintenance is to choose an LTS release. The promise of not having to do a major version upgrade for up to three years means fewer upgrade cycles and less maintenance work.
Maximizing Interoperability
It’s rare to build a Django application that doesn’t depend on other open source Django libraries. Coming across a library that’s the perfect fit for your project only to find it’s not compatible with the version of Django will slow your progress. Being a good open source community member and submitting a patch is the right thing to do, but it takes time and effort that could otherwise be spent on your application.
Open source projects are usually maintained by volunteers who are working in their free time without compensation. As a result, support can lag behind official Django releases. If you are starting development shortly after a new LTS release, it may make more sense to use the previous LTS which should have wide adoption and still have close to 9 months of support remaining. If you take this route, read the new LTS release notes carefully to future-proof your project for the jump to the next LTS. In all cases, make sure your code runs without any deprecation warnings.
Another reason to avoid jumping on a brand new LTS is to avoid any bugs that weren’t caught during testing. I generally prefer to wait for the first patch release to adopt a new LTS version (4.2.1 instead of 4.2.0). These usually show up about a month after the initial release and contain bug fixes found in the wild.
Exceptions
As with all coding rules-of-thumb, there are exceptions, but avoid getting sucked into the “it’s new-and-shiny” trap. If a newer version of Django has a killer feature that is core to your application, that might be a good reason to jump off an LTS temporarily. An example of this might be the introduction of native JSON support for Postgres in Django 1.9.
If you’re using minimal dependencies or know all your dependencies support a new LTS version, that might be a good reason to start using an LTS that was recently released. It’s easy to paint yourself into a corner with this approach however. As your project comes to life, you may find you actually do need a library you didn’t expect when you started.
Finally, if you’re developing as a hobby or to learn something new, use whatever version you want! Not every development project needs to be dictated by cost or what’s best for the business.
Tldr; Use the latest LTS which has received at least one patch release. The version number will be in the format x.2.z where z > 0. This usually isn’t the latest version you can download from PyPI.
Photo by Ehimetalor Akhere Unuabona on Unsplash
