url updates

handbook/troggle/trogdjangup.html

@@ -56,8 +56,8 @@
 </table>
 </div>
 <h4>Major, minor and releases</h4>
-<p>Django release 1.11.29 is major-version 1, minor-version 11, and patch-release 29. 1.11 is the "feature release".
-<p>Things <em>will break</em> between <a href="https://docs.djangoproject.com/en/dev/internals/release-process/">django minor-versions</a> (feature releases) which come out every 8 months. 
+<p>Django release 2.2.20 is major-version 2, minor-version 2, and patch-release 20. 2.2 is the "feature release" and patch releases within each feature release are not meant to break anything. They are just to fix bugs.
+<p>Things <em>will break</em> between <a href="https://docs.djangoproject.com/en/dev/internals/release-process/">feature releases</a> which come out every 8 months. 
 
 <h4>Django plugins ("apps")</h4>
 <p>Documentation for the plugins is highly variable and plugin projects, being run by volunteers, can just die unexpectedly. For django-registration there are two sources of current information:<br />
@@ -84,20 +84,21 @@
         python manage.py validate -v 3 --traceback<br />
         django-admin check <br />
         python manage.py test -v 3 --traceback</var>
-<li>Use the <em>highest release number</em> when upgrading between minor-versions of django. <br />So we went from 1.8.19 to 1.9.13 to 1.10.8 to 1.11.29 . Next will be 2.0.13, then 2.1.15 and then 2.2.15 .
+<li>Use the <em>highest release number</em> when upgrading between minor-versions of django. <br />So we went from 1.8.19 to 1.9.13 to 1.10.8 to 1.11.29 to 2.0.13 to 2.1.15 and then 2.2.19 .
 <li>Use the django 'check' maintenance system at the most verbose setting at each release<br />
 <var>troggle$ python manage.py check -v 3 --deploy</var><br>
 <var>troggle$ python -Wall manage.py check</var><br>
 <li>Use our test suite (and if you see errors, run it with <var>-v 3</var>)<br />
 <var>troggle$ python manage.py test [-v 3]</var><br>
-<li>Read all the release notes for <em>all</em> the intermediate releases. So from 1.1.29 we will read <a href="https://docs.djangoproject.com/en/3.0/releases/">14 sets of notes</a>: for <a href="https://docs.djangoproject.com/en/3.0/releases/2.0/">2.0</a>, 2.0.1, 2.0.2... up to 2.0.13  .
+<li>Read all the release notes for <em>all</em> the intermediate releases. So from 1.1.29 we  read <a href="https://docs.djangoproject.com/en/3.0/releases/">14 sets of notes</a>: for <a href="https://docs.djangoproject.com/en/3.0/releases/2.0/">2.0</a>, 2.0.1, 2.0.2... up to 2.0.13  .
 <li>Seriously learn how to use the traceback webpage produced by django when a page crashes. There is a full record of every variable value hidden in there.
 <li>You will be doing a lot of local testing just on your development machine. The default is to use the webserver built into Django: <var>python manage.py runserver 0.0.0.0:8000 -v 3</var>. Alternatively you can install and use gunicorn: 
 <var><a href="https://docs.gunicorn.org/en/stable/design.html">gunicorn</a> --reload -w 9 -b :8000 wsgi</var>. the '-w' flag is for the number of worker threads and should be 2n+1 where n is the number of cpu cores on your machine.
 </ol>
-<p>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).
-<p><var>--deploy</var> gives django warnings about security issues in your settings as well as django deprecation warnings.<br>
-<var>-Wall</var> 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).
+<h3>Deprecation warnings and python versions</h3>
+<p>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 .
+<p><var>check --deploy</var> gives django warnings about security issues in your settings as well as django deprecation warnings.<br>
+<var>-Wall</var> 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 . Python version compatibilities are documented at the top of each x.0 release note. From Django 3.0 it requires python 3.6.
 
 <h3>The upgrade process</h3>
 <ol>
@@ -141,31 +142,53 @@
 <li>run the script <var>./pre-run.sh</var> to clean up everything before the next round of tests.
 
 </ol>
+<h3>Django dependencies</h3>
 <p>You can upgrade the version of python installed within pip venv but not downgrade. So get that first venv installed right.
 
 <p>Here is example of installed (Version) and most-recent-available (Latest)  verisons of pip installations.
-<pre><code>$ pip list -o
-Package             Version Latest Type
-------------------- ------- ------ -----
-Django              1.11.29 3.2    wheel
-docutils            0.16    0.17   wheel
-Pillow              7.2.0   8.2.0  wheel
-pytz                2020.1  2021.1 wheel
-setuptools          45.2.0  54.2.0 wheel
-Unidecode           1.1.1   1.2.0  wheel</code></pre>
+<pre><code>Package    Version Latest Type
+---------- ------- ------ -----
+Django     2.2.19  3.2    wheel
+docutils   0.14    0.17   wheel</code></pre>
+
 <p>This only gives any output for packages which are not the most recent. To see what is actually installed use
 <pre><code>$ pip freeze
 confusable-homoglyphs==3.2.0
-Django==1.11.29
-docutils==0.16
-Pillow==7.2.0
-pytz==2020.1
-Unidecode==1.1.1</code></pre>
-<p>To upgrade pip istelf, do <var>$ pip install --upgrade pip</var>
-<p>We will not need to anything until we move from django 2.2.15+ to 3.2+ which <a href="trog2030.html">we may never do</a>.
+Django==2.2.19
+docutils==0.17
+Pillow==8.2.0
+pytz==2021.1
+sqlparse==0.4.1
+Unidecode==1.2.0</code></pre>
+
+Although the above all work fine, on debian <var>buster</var> we are actually using the standard installs which are older:
+<pre><code>$ pip freeze
+confusable-homoglyphs==3.2.0
+Django==2.2.19
+docutils==0.14
+Pillow==5.4.1
+pytz==2019.1
+sqlparse==0.2.4
+Unidecode==1.0.23</code></pre>
+
+<p>To upgrade pip istelf, do <var>$ pip install --upgrade pip</var>
+
+<h3>Django database dependencies</h3>
+<p>On the expo server we run MariaDB as the database which has its own dependencies. In particular
+
+<pre><code>mysqlclient==1.3.10
+</code></pre>which is technically incompatible with Django 2.2 which requires 1.3.13. This incompatibility is a policy choice by the Django team. Wookey ran the Django system tests with this (April 2020) and it works fine.
+
+<h4>To run Django's system test suite:</h4>
+
+Follow the instructions in the "Unit tests" section installed locally at docs/internals/contributing/writing-code/unit-tests.txt, published online at <a href="https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#running-the-unit-tests">docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/</a>
+This involves running <var>git clone</var> on the django source repo to download the tests.  We hope we never have to do this again but in case we get incomprehensible bugs in future, we should be prepared to do so.
 
-<p>Current upgrade status is documented: <a href="trogstatus.html">here</a>.
 <hr />
+<p>We should not need to anything until we move from django 2.2 LTS to 3.2 LTS which <a href="trog2030.html">we may never do</a>.
+<p>Current upgrade status is documented: <a href="trogstatus.html">here</a>.
+<p>
+
 Go on to: <a href="trogarch.html">Troggle architecture</a><br />
 Return to: <a href="trogintro.html">Troggle intro</a><br />
 Troggle index: