Django 4.0 is out and so is Django 3.2.10. Which one should you go for?
3.2.10 is the last minor release of this LTS version. The release notes say:
The final minor bug fix release, 3.2.10, was issued today. Django 3.2 is an LTS release and will receive security and data loss fixes until April 2024.
This means there will be no 3.3 (which would be the next minor version). 3.2 will still get patches, but only for critical issues like security vulnerabilities.
Regularly readers of this blog will know that I’m a big fan of LTS (Long Term Support) software. Now is a great time to build something with Django 3.2. You’ll only have to patch it if it’s absolutely necessary. It’s not a great idea to use the latest major version of software if you want stability and reliability. There will be bugs.
The next Django LTS release is 4.2. I’d wait a couple of years and upgrade to that, unless there are some features that you really want.
4 Features
There are a few new features in 4.0, including changing the default timezone implementation. The number of iterations for the PBKDF2 password hasher has been increased and a new scrypt hasher has been added (although it is not the default). There’s also a new Redis cache backend as an alternative to the existing options such as Memcached.
While these are all good, it’s more evolution than revolution. Unless any of these are particularly compelling then you probably want to simply upgrade 3.2 to the latest patch level.
How To Upgrade 3.2
Be careful of upgrading without specifying a version number. This will bump you to 4.0.
You could simply use django==3.2.10 but this isn’t future proof. It’s better to use "django>=3.2.10,<3.3". You could probably use "django>=3.2.10,<4.0" but it’s safer to set 3.3 as the upper limit. Note the quotes, these may be needed to escape the comma depending on how you use this.
You may think that you could just specify 3.2 and get the latest patch level but unfortunately this is not the case. You’d actually get the earliest 3.2 release, which is not good. Django doesn’t use Semantic Versioning correctly and there is no patch version for first major or minor release, which is troublesome. For example, 3.2 is not 3.2.0, it’s just 3.2. Similarly, 4.0 isn’t 4.0.0, which would be more helpful.
Semantic Versioning should be in the form MAJOR.MINOR.PATCH (and if unstable then an optional - label for pre-release versions).
A normal version number MUST take the form X.Y.Z
Python gets this right and 3.10.0 is not just 3.10. Python 3.10.1 is also out now, so you should upgrade if you are not still on 3.9. I would typically stick with Python 3.9 but Django recommends the latest as does Heroku.
If you use pyenv to manage your Python versions then this has already been updated to 3.10.1, so you can pyenv update if have the update plugin (from the installer). Then you can pyenv install 3.10.1 and set it as the version to use e.g. pyenv global 3.10.1.
I’m also using PostgreSQL but I wouldn’t jump on version 14 just yet. PostgreSQL is a pretty mature project but they have still been known to have issues. They use a different version numbering system to Python so you want to be on the latest minor release (for modern versions at least) to get the latest security updates e.g. currently 13.5 or 12.9.
PostgreSQL security updates are primarily made available as minor version upgrades. You are always advised to use the latest minor version available, as it will likely also contain other non-security related fixes. All known security issues are always fixed in the next major release, when it comes out.
One thing to note if you are using AWS RDS is the lag in updates. AWS have been known to release a new version of PostgreSQL to RDS that’s not the latest and already has a newer security patch out for it. You may be “upgrading” to an out-of-date vulnerable version that has already has a fix made available. A client of mine got bitten by a security issue this way. The lesson here is don’t upgrade to a new major version too quickly and always check the release notes of the underlying software (especially if upgrading to a new major version).
It can be better in some ways to host your own software and you also avoid lock-in by doing this (although services like RDS and ElasticCache are pretty portable if you can run the software yourself). It’s a trade-off, you get more freedom and flexibility but the maintenance burden is higher.
If you use agnostic technology like the HashiStack or Docker containers then you can keep your software portable. It’s a good idea to integrate this all into a continuous delivery system as well, to reduce errors and improve consistency.
Finally, if you use AWS then pick one of the four public regions that use Renewable Energy Credits and Guarantees of Origin. In Europe, I would go with Ireland over Germany as the carbon intensity of the electricity generation is lower and they don’t burn open-cast lignite.
However, other clouds and hosts are available. Do you really want to support a company with the environmental and ethical credentials of Amazon anyway?