Troggle is built on top of the django framework. In 2019 we had let ourselves get rather behind in keeping up to date with the django version and this held us back from upgrading the operating system - which we needed to do. Troggle uses several community-contributed django plugins and each of these had their own version dependencies. We also got caught up with out of date and deprecated python language features.
A ridiculous amount of work was required to get to a situation where troggle was running on relatively recent and nearly security-in-date versions of python, django, plugins and linux by Summer 2020. We don't want that to happen again.
When django upgrades to a new version things break across the entire django package, including things which we don't conciously use but are internal dependencies within django. These were 'the way to do it' when troggle was first written for django 0.7 in 2006. So upgrading troggle to a new django version requires not just a broad beadth of knowledge across troggle, but also across the entire breadth of django itself. And the error messages are sometimes very unhelpful.
Django release 1.11.29 is major-version 1, minor-version 11, and patch-release 29. 1.11 is the "feature release".
Things will break between django minor-versions which come out every 8 months.
But the contributed plugins have no such management process and releases are rather random, e.g. for django-registration there are two sources of current information:
Docs: django-registration 3.1
PyPi: django-registration 3.1
but only one of these (PyPi) gives release history data - which is what you need if you get behind with the django upgrades.
Django plugin documentation cannot be relied upton to tell you which version of django they require. They will complain when you run them if your version of django is too old though. Some experimentation is required.
Every extra plugin increases the "vulnerability surface" of troggle with respect to django upgrade problems so only install a new plugin if it is really, really necessary. For example, when django-staticfiles broke during one upgrade we discovered that we could use flatfiles as a workaround, so we are not planning on reinstalling staticfiles ever again.
[ However django-extensions looks like it could be useful explicitly to help us through the upgrade process: pypi.org/project/django-extensions/ (only available for django 2.2 and later). ]
There are five critical tricks that make everything much, much easier:
The individual releases within a minor version don't break anything but do fix bugs. So if you are on 1.10.x there is no point in getting 1.11.1 to work and you should go straight to 1.11.29 (29 is the highest release number in minor version 1.11).
--deploy gives django warnings about security issues in your settings as well as django deprecation warnings.
-Wall is a standard python option and gives warnings of deprecated python features used by django and all the current plugins. So it tells us that django 1.11.29 is using a deprecated python language feature which will be removed from the language in python 3.9 (in fact 1.11.29 is incompatible with python 3.8 too but we didn't get a warning about that).
You can upgrade the version of python installed within pip but not downgrade. So get that first venv installed right.
Here is example of installed (Version) and most-recent-available (Latest) verisons of pip installations.
$ pip list -o
Package Version Latest Type
------------------- ------- ------ -----
Django 1.11.29 3.0.8 wheel
django-registration 2.5.2 3.1 wheel
Pillow 7.1.2 7.2.0 wheel
setuptools 45.2.0 49.2.0 wheel
This only gives any output for packages which are not the most recent. To see what is actually installed use
$ pip freeze
confusable-homoglyphs==3.2.0
Django==1.11.29
django-registration==2.5.2
docutils==0.16
Pillow==7.2.0
pytz==2020.1
Unidecode==1.1.1
To upgrade pip istelf, do $ pip install --upgrade pip
We will not need to update the django-registration until we move from django 2.2.15+ to 3.0.9+ which we may never do.