We also need to take care about deployment issues. We are using Django 2.2 also because we are currently using Debian packages and python3-django in buster-backports is 2.2. The plan was to move away from using Debian packages but only swh-graphql is deployed using the new method. (Finding an issue to refer would be nice.)
If you’re upgrading through more than one feature version (e.g. 2.0 to 2.2), it’s usually easier to upgrade through each feature release incrementally (2.0 to 2.1 to 2.2) rather than to make all the changes for each feature release at once. For each feature release, use the latest patch release (e.g. for 2.1, use 2.1.15).
So probably we should create a different issue for each feature version (3.0, 3.1, 3.2, 4.0). Then we can create a checklist to review all backward incompatible changes for each feature version as they are mentioned in the release notes.
Maybe using a docker dev environment wired to the staging (first then prod) instance to install incrementally each new django version (in the container pip-enabled) could help.
(I'm guessing those versions are doing some incremental upgrade in the internal django model or something.)
So probably we should create a different issue for each feature version (3.0, 3.1, 3.2, 4.0). Then we can create a checklist to review all backward incompatible changes for each feature version as they are mentioned in the release notes.
That would not be necessary as fortunately we added support for all these django versions in swh-web over the last years thanks to the jenkins job building debian unstable package for it. We already took care of removing any deprecated features we were using. Only a couple of deprecation warnings related to django remain but those are easily fixable.
I do not expect the django upgrade to 4.1 to be painful. Bumping django to 4.1 locally, only one Python test and one cypress test are failing and I found the fixes.
The only important thing we must care about is to ensure django migrations will be executed with the new deployment system. Currently, these operations are executed as a postinst step when installing the debian package.