#django

Django 4.2 LTS to 5.2 LTS Upgrade Planner: Python 3.10+ Floor, Stepwise 5.0 and 5.1 Hops, python -Wa Deprecation Sweep, django-upgrade Codemods, STORAGES Setting, index_together and pytz Removals, and a Third Party Package Matrix

Plan a Django upgrade from 4.2 LTS to 5.2 LTS as a series of safe hops: environment floors, a deprecation sweep with warnings turned on, django-upgrade codemods, the removals that actually break 4.2 code, a package compatibility matrix, migration checks, and a deploy and rollback plan for each step.

Act as a senior Django engineer who has moved several production apps from one LTS release to the next, upgrades one minor version at a time, and lets the deprecation warnings drive the work list. Inputs: - Current versions: Django, Python, database engine and version, OS image: [CurrentStack] - requirements or pyproject dependency list with pinned versions: [Dependencies] - Settings excerpts and code patterns you know you use (storage settings, timezone handling, custom auth, model Meta options, test helpers): [SettingsAndPatterns] - Test suite size, CI setup, and how long a full run takes: [TestSuite] - Deploy method and tolerance for downtime: [DeployContext] - Output format: [Format] Generate: 1. Floors table: Django 5.x needs Python 3.10 or newer, and each release raises database minimums (for PostgreSQL, 5.2 expects 14 or newer). Compare against CurrentStack and list what must move first. 2. Hop plan: 4.2 to 5.0, then 5.1, then 5.2, each its own branch and deploy. Never jump straight to 5.2. 3. Warning sweep for each hop: run the suite with python -Wa manage.py test (or PYTHONWARNINGS=always with pytest), collect RemovedInDjango warnings, and fix all of them before bumping the version. 4. Codemods: run django-upgrade with --target-version for the hop, and pyupgrade for the Python floor, then review the diff by hand. 5. Breaking removals mapped to SettingsAndPatterns, for example: DEFAULT_FILE_STORAGE and STATICFILES_STORAGE replaced by STORAGES, index_together replaced by Meta.indexes with a migration, pytz support and USE_DEPRECATED_PYTZ removed in favor of zoneinfo, USE_L10N removed, logout over GET removed, assertQuerysetEqual renamed to assertQuerySetEqual, CheckConstraint check renamed to condition. For each: file, fix, test. 6. Package matrix from Dependencies: package, current pin, first version that supports the target Django, blocker yes or no, and an alternative if abandoned. 7. Migration safety: makemigrations --check after each hop, review any generated migration, and run migrations against a production sized copy. 8. Deploy and rollback for each hop from DeployContext, including what to watch in logs for the first day. 9. Mark anything you cannot confirm from the official release notes as "check the 5.x release notes". Constraints: - Ordered, checkable steps. Show commands exactly. No em dashes.