Update all refs to 5.1 -> 5.2 in the text

Author: hjwp

chapter_01.asciidoc

@@ -227,7 +227,7 @@ You have 18 unapplied migration(s). Your project may not work properly until
 you apply the migrations for app(s): admin, auth, contenttypes, sessions.
 Run 'python manage.py migrate' to apply them.
 March 17, 2023 - 18:07:30
-Django version 5.1.4, using settings 'superlists.settings'
+Django version 5.2.4, using settings 'superlists.settings'
 Starting development server at http://127.0.0.1:8000/
 Quit the server with CONTROL-C.
 ----

chapter_03_unit_test_first_view.asciidoc

@@ -282,7 +282,7 @@ and the view part is actually provided by the templates,
 but you can see the general idea is there!
 
 If you're interested, you can look up the finer points of the discussion
-https://docs.djangoproject.com/en/5.1/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names[in the Django FAQs].
+https://docs.djangoproject.com/en/5.2/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names[in the Django FAQs].
 
 Irrespective of any of that, as with any web server, Django's main job is to
 decide what to do when a user asks for a particular URL on our site.
@@ -692,7 +692,7 @@ How can we write a test for URL resolution?
 At the moment we just test the view function directly by importing it and calling it.
 But we want to test more layers of the Django stack.
 Django, like most web frameworks, supplies a tool for doing just that, called the
-https://docs.djangoproject.com/en/5.1/topics/testing/tools/#the-test-client[Django Test Client].
+https://docs.djangoproject.com/en/5.2/topics/testing/tools/#the-test-client[Django Test Client].
 
 // CSANAD: it might be a little confusing first why we add a _unit_ test, considering this second
 //         test case is closer to a user's point of view. We could point out this to be one example
@@ -864,7 +864,7 @@ Let's go take a look:
 URL configuration for superlists project.
 
 The `urlpatterns` list routes URLs to views. For more information please see:
-    https://docs.djangoproject.com/en/5.1/topics/http/urls/
+    https://docs.djangoproject.com/en/5.2/topics/http/urls/
 Examples:
 Function views
     1. Add an import:  from my_app import views

chapter_04_philosophy_and_refactoring.asciidoc

@@ -399,7 +399,7 @@ Some people like to use another subfolder named after the app
 This is called "template namespacing".
 I figured it was overcomplicated for this small project, but it may be worth it on larger projects.
 There's more in the
-https://docs.djangoproject.com/en/5.1/intro/tutorial03/#write-views-that-actually-do-something[Django tutorial].]
+https://docs.djangoproject.com/en/5.2/intro/tutorial03/#write-views-that-actually-do-something[Django tutorial].]
 
 [role="sourcecode"]
 .lists/templates/home.html (ch04l002)

chapter_05_post_and_database.asciidoc

@@ -1052,9 +1052,9 @@ Django has many other field types, like `IntegerField`, `CharField`,
 `DateField`, and so on.  I've chosen `TextField` rather than `CharField` because
 the latter requires a length restriction, which seems arbitrary at this point.
 You can read more on field types in the Django
-https://docs.djangoproject.com/en/5.1/intro/tutorial02/#creating-models[tutorial]
+https://docs.djangoproject.com/en/5.2/intro/tutorial02/#creating-models[tutorial]
 and in the
-https://docs.djangoproject.com/en/5.1/ref/models/fields/[documentation].
+https://docs.djangoproject.com/en/5.2/ref/models/fields/[documentation].
 
 
 
@@ -1694,7 +1694,7 @@ will render with multiple `<tr>` rows, one for each item in the variable
 `items`.  Pretty neat!  I'll introduce a few more bits of Django template
 magic as we go, but at some point you'll want to go and read up on the rest of
 them in the
-https://docs.djangoproject.com/en/5.1/topics/templates/[Django docs].
+https://docs.djangoproject.com/en/5.2/topics/templates/[Django docs].
 
 Just changing the template doesn't get our tests to green; we need to actually
 pass the items to it from our home page view:
@@ -1762,7 +1762,7 @@ called 'db.sqlite3' in the base project directory:
 ----
 [...]
 # Database
-# https://docs.djangoproject.com/en/5.1/ref/settings/#databases
+# https://docs.djangoproject.com/en/5.2/ref/settings/#databases
 
 DATABASES = {
     "default": {

chapter_07_working_incrementally.asciidoc

@@ -1115,7 +1115,7 @@ TIP: This is another place to pay attention to trailing slashes, incidentally.
 // as we can have different methods on the same URL.
 // Also, the way our Django app is configured, it will automatically redirect to a URL
 // with the slash appended, so I'm not sure this makes much sense.
-// https://docs.djangoproject.com/en/5.1/ref/settings/#append-slash
+// https://docs.djangoproject.com/en/5.2/ref/settings/#append-slash
 
 Try running that:
 
@@ -2352,7 +2352,7 @@ which is what we were trying to do anyway:
 <1> There's our new form action.
 
 <2> `.item_set` is called a
-    https://docs.djangoproject.com/en/5.1/topics/db/queries/#following-relationships-backward[reverse lookup].
+    https://docs.djangoproject.com/en/5.2/topics/db/queries/#following-relationships-backward[reverse lookup].
     It's one of Django's incredibly useful bits of ORM that lets you look up an
     object's related items from a different table.
     ((("reverse lookups")))

chapter_08_prettification.asciidoc

@@ -649,7 +649,7 @@ It's defined in _settings.py_:
 [...]
 
 # Static files (CSS, JavaScript, Images)
-# https://docs.djangoproject.com/en/5.1/howto/static-files/
+# https://docs.djangoproject.com/en/5.2/howto/static-files/
 
 STATIC_URL = "static/"
 ----
@@ -696,7 +696,7 @@ To get it to work, we need to change it to:
 ====
 
 // DAVID: Django best practice would be to use the static tag instead.
-// https://docs.djangoproject.com/en/5.1/howto/static-files/#configuring-static-files
+// https://docs.djangoproject.com/en/5.2/howto/static-files/#configuring-static-files
 
 Now when `runserver` sees the request,
 it knows that it's for a static file because it begins with `/static/`.
@@ -729,7 +729,7 @@ That's because, although `runserver` automagically finds static files,
 Never fear, though:
 the Django developers have made an even more magical test class
 called `StaticLiveServerTestCase`
-(see https://docs.djangoproject.com/en/5.1/ref/contrib/staticfiles/#django.contrib.staticfiles.testing.StaticLiveServerTestCase[the docs]).
+(see https://docs.djangoproject.com/en/5.2/ref/contrib/staticfiles/#django.contrib.staticfiles.testing.StaticLiveServerTestCase[the docs]).
 
 // JAN: Maybe you could mention that StaticLiveServerTestCase inherits from LiveServerTestCase - so all previous should work + static files. After reading the name, I imagined StaticLiveServerTestCase as some special test class for testing only static-related stuff
 
@@ -1010,7 +1010,7 @@ making it relative to the location of the project base directory:
 [source,python]
 ----
 # Static files (CSS, JavaScript, Images)
-# https://docs.djangoproject.com/en/5.1/howto/static-files/
+# https://docs.djangoproject.com/en/5.2/howto/static-files/
 
 STATIC_URL = "static/"
 STATIC_ROOT = BASE_DIR / "static"

chapter_09_docker.asciidoc

@@ -882,7 +882,7 @@ System check identified no issues (0 silenced).
 
 You have 19 unapplied migration(s). Your project may not [...]
 [...]
-Django version 5.1.4, using settings 'superlists.settings'
+Django version 5.2.4, using settings 'superlists.settings'
 Starting development server at http://127.0.0.1:8000/
 Quit the server with CONTROL-C.
 ----

chapter_10_production_readiness.asciidoc

@@ -298,7 +298,7 @@ $ *pip freeze*
 asgiref==3.8.1
 attrs==23.2.0
 certifi==2024.2.2
-django==5.1.4
+django==5.2.4
 gunicorn==21.2.0
 h11==0.14.0
 idna==3.6
@@ -326,7 +326,7 @@ Django, Gunicorn and Whitenoise:
 [subs="specialcharacters,quotes"]
 ----
 $ *pip freeze | grep -i django*
-Django==5.1.[...]
+Django==5.2.[...]
 
 $ *pip freeze | grep -i django >> requirements.txt*
 $ *pip freeze | grep -i gunicorn >> requirements.txt*
@@ -341,7 +341,7 @@ That should give us a requirements.txt file that looks like this:
 ====
 [source,python]
 ----
-django==5.1.4
+django==5.2.4
 gunicorn==21.2.0
 whitenoise==6.6.0
 ----
@@ -459,7 +459,7 @@ _settings.py_ that we want to change for production:
   because that code might be visible to strangers.
   We'll want to generate a new, random one
   but then keep it the same for the foreseeable future
-  (find out more in the https://docs.djangoproject.com/en/5.1/topics/signing/[Django docs]).
+  (find out more in the https://docs.djangoproject.com/en/5.2/topics/signing/[Django docs]).
 
 Development, staging and production sites always have some differences
 in their configuration.
@@ -641,7 +641,7 @@ By default, when DEBUG=True, `ALLOWED_HOSTS` effectively allows _localhost_,
 our own machine, so that's why it was working OK until now.
 
 There's more information in the
-https://docs.djangoproject.com/en/5.1/ref/settings/#allowed-hosts[Django docs].
+https://docs.djangoproject.com/en/5.2/ref/settings/#allowed-hosts[Django docs].
 
 The upshot is that we need to adjust `ALLOWED_HOSTS` in _settings.py_.
 Let's use another environment variable for that:
@@ -860,7 +860,7 @@ but it's more of shock to see that they are no longer appearing in the terminal
 If you're like me you might find yourself wondering if we really _did_ see them earlier
 and starting to doubt your own sanity.
 But the explanation is that Django's
-https://docs.djangoproject.com/en/5.1/ref/logging/#default-logging-configuration[default logging configuration]
+https://docs.djangoproject.com/en/5.2/ref/logging/#default-logging-configuration[default logging configuration]
 changes when DEBUG is turned off.
 
 This means we need to interact with the standard library's `logging` module,

chapter_14_database_layer_validation.asciidoc

@@ -150,7 +150,7 @@ But all is not quite as it seems,
 because _this test should already pass_.
 
 If you take a look at the
-https://docs.djangoproject.com/en/5.1/ref/models/fields/#blank[docs for the Django model fields],
+https://docs.djangoproject.com/en/5.2/ref/models/fields/#blank[docs for the Django model fields],
 you'll see under _Field options_ that the default setting for _all_ fields is
 `blank=False`.
 Since TextField is a type of Field, it _should_ already disallow empty values.
@@ -289,7 +289,7 @@ Django models don't run full validation on save.
 ((("full_clean method")))
 Django does have a method to manually run full validation, however,
 called `full_clean` (more info in
-https://docs.djangoproject.com/en/5.1/ref/models/instances/#django.db.models.Model.full_clean[the docs]).
+https://docs.djangoproject.com/en/5.2/ref/models/instances/#django.db.models.Model.full_clean[the docs]).
 Let's swap that for the `.save()` and see if it works:
 
 
@@ -559,7 +559,7 @@ self.assertContains(response, expected_error)
 ====
 
 ...will show us the cause—Django has
-https://docs.djangoproject.com/en/5.1/ref/templates/builtins/#autoescape[HTML-escaped]
+https://docs.djangoproject.com/en/5.2/ref/templates/builtins/#autoescape[HTML-escaped]
 the apostrophe:
 
 [subs="specialcharacters,macros"]
@@ -1225,7 +1225,7 @@ a [keep-together]#parameter#:
 ====
 
 See the
-https://docs.djangoproject.com/en/5.1/topics/http/urls/#reverse-resolution-of-urls[Django
+https://docs.djangoproject.com/en/5.2/topics/http/urls/#reverse-resolution-of-urls[Django
 docs on reverse URL resolution] for more info. We run the tests again, and check that they all pass:
 
 [subs="specialcharacters,macros"]
@@ -1309,7 +1309,7 @@ AttributeError: 'List' object has no attribute 'get_absolute_url'
 The implementation is to use Django's `reverse` function, which
 essentially does the reverse of what Django normally does with _urls.py_
 (see the
-https://docs.djangoproject.com/en/5.1/topics/http/urls/#reverse-resolution-of-urls[docs]):
+https://docs.djangoproject.com/en/5.2/topics/http/urls/#reverse-resolution-of-urls[docs]):
 
 
 [role="sourcecode"]
@@ -1343,7 +1343,7 @@ def new_list(request):
 ====
 
 There's more info in the
-https://docs.djangoproject.com/en/5.1/topics/http/shortcuts/#redirect[Django docs].
+https://docs.djangoproject.com/en/5.2/topics/http/shortcuts/#redirect[Django docs].
 Quick check that the unit tests still pass:
 
 [subs="specialcharacters,macros"]

chapter_15_simple_form.asciidoc

@@ -249,7 +249,7 @@ and which fields we want it to use.
 like assigning sensible HTML form input types to different types of field,
 and applying default validation.
 Check out the
-https://docs.djangoproject.com/en/5.1/topics/forms/modelforms/[docs]
+https://docs.djangoproject.com/en/5.2/topics/forms/modelforms/[docs]
 for more info.
 
 We now have some different-looking form HTML:
@@ -1208,7 +1208,7 @@ using a form is a nice way of encapsulating that logic.
 // DAVID: I wonder if this is slightly missing the point.
 // Our functional tests here are very high level - using a headless browser.
 // But many developers use the Django test client
-// (https://docs.djangoproject.com/en/5.1/topics/testing/tools/#the-test-client)
+// (https://docs.djangoproject.com/en/5.2/topics/testing/tools/#the-test-client)
 // for this kind of thing, which doesn't have browser validation built in.
 // So we could use that if we really wanted to test the server side validation.
 //