Django 5.0

Django 5.0 added schema-level database defaults through Field.db_default and database-generated columns through GeneratedField, allowing some values and expressions to be evaluated by the database rather than only in Python. It expanded field choices so they can be declared with mappings and callables, added facet counts to the admin’s changelist filters, and added asynchronous signal dispatch plus asynchronous variants of core authentication operations. It also raised the minimum supported Python version and removed compatibility paths that had previously been deprecated. These changes can affect migration output, database portability, custom admin behavior, async code paths, and environments still running older Python interpreters.

This cycle has reached end of life, so Django no longer provides fixes for security issues, defects, or compatibility problems in this line. Remaining on it leaves the application dependent on its final dependency and database compatibility envelope; newly discovered vulnerabilities may require local patches or compensating controls rather than an upstream update. The longer a team stays, the more its package constraints, Python runtime, database drivers, and third-party Django packages can diverge from supported combinations, making the eventual upgrade larger and harder to test. Features introduced in this cycle, particularly database defaults and generated fields, can also create migration and backend-specific behavior that must be understood before changing Django or database versions.

Choose a currently supported Django target that is compatible with the team’s required Python version, database backend, and major third-party packages. Read the upgrade and deprecation notes for every intervening Django feature release, then update dependencies in a controlled branch and run django-admin check, the full test suite, and deployment checks against production-like settings. Review all migrations that use db_default or GeneratedField, verify the resulting schema and behavior on the production database engine, and test rollback and restore procedures. Exercise admin filters, authentication flows, signal handlers, asynchronous views, management commands, and background workers, because custom integrations often rely on APIs or synchronous assumptions affected by later releases. Deploy through a staged environment, monitor errors and query behavior, and keep the old and new dependency lockfiles available until the upgrade is validated.