Django 5.1

Django 5.1 added built-in Content Security Policy support, including middleware and settings for enforcing or report-only policies. It added LoginRequiredMiddleware, which makes authentication required by default and allows explicitly public views to opt out with login_not_required(). PostgreSQL deployments using psycopg gained optional database connection pooling configuration. The template system gained a querystring tag for constructing URLs while preserving and changing query parameters. This cycle also added support for newer supported Python versions and continued the usual deprecation path for older Django APIs and behaviors.

Django 5.1 has reached end of life. Security issues, data-loss or correctness bugs, and compatibility regressions discovered in this line will not receive upstream fixes. The practical exposure grows as Python, database drivers, operating systems, browsers, and third-party Django packages move their tested support forward. Remaining on 5.1 can also turn a routine upgrade into a larger migration: dependencies may eventually require a newer Django version, while code that still relies on APIs deprecated in 5.1 or later will accumulate more changes to resolve. Applications that enabled the new CSP, login middleware, or connection pooling features should treat their configuration as production behavior to retest rather than assuming it transfers unchanged.

Plan an upgrade to a currently supported Django release, selecting an LTS target when that fits the team's maintenance policy. First inventory the supported Python version, database backend and driver, and every Django integration package; confirm that all of them support the target Django version. Read the release notes and deprecation notes for every version crossed, then remove uses of deprecated APIs before or during the upgrade. Upgrade in a representative environment, run Django's system checks, apply and test migrations, and execute the full application and integration test suite. Specifically test authentication and public endpoints if LoginRequiredMiddleware is enabled, CSP headers and third-party browser integrations if CSP is enabled, and connection behavior under load if PostgreSQL pooling is configured. Deploy with monitoring for exceptions, database connection saturation, failed background jobs, and client-side CSP violations, and retain a tested rollback plan.