Django 3.2

Django 3.2 introduced configurable default primary-key types through DEFAULT_AUTO_FIELD and AppConfig.default_auto_field, allowing new models to use BigAutoField without declaring it on every model. It added automatic discovery of application configuration classes, PostgreSQL support for functional and covering indexes, and a number of ORM, admin, forms, and template improvements. It also continued Django’s transition toward async-capable request handling, while retaining the synchronous interfaces used by existing applications. The default-primary-key change is the migration-sensitive feature: projects upgrading to this line can see warnings for models whose implicit AutoField primary key has not been made explicit or configured deliberately.

Django 3.2 has reached end of life and no longer receives upstream security or bug fixes. Remaining on it leaves framework vulnerabilities and correctness issues to be mitigated locally, and makes it progressively harder to adopt supported Python versions, database drivers, deployment tooling, and third-party Django packages. The longer an application stays on this line, the more likely its dependencies will require incompatible versions or its own code will rely on APIs removed by later Django releases. Teams also retain the operational risk of an unsupported framework component in security reviews, incident response, and compliance processes.

Choose a currently supported Django target that is compatible with the application’s required Python version and key third-party packages. Inventory dependencies, pin a reproducible test environment, and review the Django release notes and deprecation warnings for every intervening upgrade step. Before changing versions, make implicit primary-key choices explicit where appropriate by setting DEFAULT_AUTO_FIELD or AppConfig.default_auto_field, and generate and review any resulting migrations rather than applying schema changes blindly. Upgrade in tested stages, run the full test suite and system checks, validate migrations and query plans against production-like databases, and test authentication, admin workflows, async or synchronous request paths, background jobs, and deployment configuration. Deploy with rollback-ready database and application procedures, then remove compatibility workarounds once the supported target is stable.