Upgrade to Django 5.0

[a-musing-moose]

🎯Aim

Ensure that the template project is upgraded to work with Django 5.0

📕Context

Django 5.0 was release on the 4th December and we should ensure that the template project is compatible.

This may involve upgrading other libraries along the way. It is possible that the may not all be compatible yet. In this instance we would want to wait before updating to Django 5.0. So I recognise this issue may be open for a while.

We should also run startproject with Django 5.0 independently of this repository in order to compare the files it process (like settings.py, wsgi.py, manage.py etc.) to accommodate any major changes in approach.

📝Relevant resources/doc's/people

• Django 5.0 Release Notes

✅Acceptance Criteria

• The projects generated from this repository use Django 5.0
• Updates individual template file where the version generated by Django 5.0 differ significantly from what we currently have.

[G-Rath]

Note that Django v5 is not an LTS version and so will stop getting support a whole year before the current LTS version does - generally we prefer to stick with LTS versions though if there's a way we can ensure we're compatible with v5.x that would be smart

[a-musing-moose]

Note that Django v5 is not an LTS version and so will stop getting support a whole year before the current LTS version does - generally we prefer to stick with LTS versions though if there's a way we can ensure we're compatible with v5.x that would be smart

Forgive me if I am explaining something you already know, but Django has a slightly odd but I think quite good approach to versioning. The deprecation policy in particular is relevant here. It effectively boils down to:

• X.0
• X.1
• X.2 LTS
• Y.0: Drop deprecation shims added in X.0 and X.1.
• Y.1: Drop deprecation shims added in X.2.
• Y.2 LTS: No deprecation shims dropped (while Y.0 is no longer supported, third-party apps need to maintain compatibility back to X.2 LTS to ease LTS to LTS upgrades).
• Z.0: Drop deprecation shims added in Y.0 and Y.1.

So if we are able to run a site with X.2 and no warnings then it is also Y.0 compatible.

The approach they take is intended to allows easy migration from one version to another. Giving plenty of time and support with ensuring your code base is ready for the next release. Guiding your hand somewhat.

Sticking with LTS releases only will, I think, make the ongoing maintenance harder because each upgrade is a major jump with none of the intermediate shims and warnings to give you a helping hand.

That said, I think it is still worth discussing the trade-offs between the 2 approaches at little further

[G-Rath]

Sticking with LTS releases only will, I think, make the ongoing maintenance harder because each upgrade is a major jump with none of the intermediate shims and warnings to give you a helping hand.

Inversely, using non-LTS versions means we need to upgrade sooner to ensure we can remain secure.

I think lets take this discussion into Slack for a bit since it's related to some wider internal processes.