Django 4.0

Django 4.0 raised the minimum supported Python version by dropping Python 3.6 and 3.7. It introduced a built-in Redis cache backend, an scrypt password hasher, QuerySet.contains(), and template-based form rendering as the default rendering approach. It added support for Python's standard-library zoneinfo time zones while providing a transition path for projects still using pytz. It also made several compatibility-breaking removals of APIs that had been deprecated in earlier Django releases, including django.conf.urls.url(), older ugettext translation aliases, and force_text() and smart_text(). Some security-related configuration became stricter: CSRF_TRUSTED_ORIGINS entries must include a URL scheme such as https://.

Django 4.0 has reached end of life, so it no longer receives security fixes or bug fixes. A newly disclosed issue in Django will not be corrected for this release line, leaving teams to accept the exposure, maintain a local patch, or upgrade under pressure. Its supported Python range is also old enough to constrain runtime upgrades, while newer package, database-driver, observability, and deployment-tool releases may no longer test against it. Remaining on 4.0 therefore increases the likelihood that routine platform changes become compatibility incidents and makes the eventual framework upgrade larger because deprecations and removals accumulate across later releases.

Choose a currently supported Django target that is compatible with the team's required Python version and third-party packages. First upgrade the application to the latest available patch release in the 4.0 line to establish a stable starting point, then review the release notes and deprecation documentation for every intervening Django release on the path to the target. Inventory dependencies, including Django add-ons, database drivers, authentication integrations, and deployment tooling, and confirm their supported Django and Python ranges before changing the framework version. Run the full test suite and add coverage for forms, URL routing, time-zone handling, cache behavior, authentication, and CSRF-protected requests; these areas are particularly likely to expose framework or configuration assumptions. Test the upgrade in a production-like environment, deploy with monitoring and a rollback plan, and remove compatibility shims once the new supported version is operating normally.