Django 5.2

Django 5.2 is a long-term-support line whose headline change is first-class model support for composite primary keys. A model can declare a CompositePrimaryKey over multiple existing fields, and its pk value is represented as the combined key. This makes schemas that use multi-column identifiers more practical to model without inventing a surrogate key. The feature has important boundaries: relationship fields, including ForeignKey and GenericForeignKey, do not support composite primary keys, and composite-key models have limitations in the admin. The release also adds HttpRequest.get_preferred_type() for choosing a response media type from the client’s Accept header, and HttpResponse.text as a decoded-text convenience alongside byte-oriented response content. As with every Django feature release, it also advances supported platform combinations and begins deprecation paths that later releases will remove.

Remaining on Django 5.2 is a supported and generally low-risk position while the line matches the team’s Python, database, and dependency constraints. The immediate operational risk is therefore lower than it would be on an unsupported line, provided maintenance updates within 5.2 are applied promptly. The trade-off is that application code and third-party packages will increasingly target later Django APIs and supported platform versions. Deferring a later upgrade also allows deprecation warnings, dependency constraints, and database or Python compatibility work to accumulate. Teams using composite primary keys should be particularly cautious: adopting them can constrain future model relationships and admin usage, so a later schema reversal may be more expensive than retaining a conventional single-column primary key.

Move first to the latest available 5.2 maintenance release and run the full test suite with deprecation warnings visible. Run python manage.py check --deploy in each production-like configuration, and confirm the supported Python, database, driver, cache, and third-party-package versions against Django’s compatibility requirements. Review migrations on a production-shaped database copy, especially where primary keys, constraints, or relationships are involved. Treat composite primary keys as an explicit architecture decision: prototype the required queries, migrations, relationships, and admin workflows before adopting them, and do not assume ForeignKey or GenericForeignKey support. If the application negotiates response formats, add tests for Accept-header behavior before using get_preferred_type(). Then plan a separate upgrade to a later Django line by removing 5.2 deprecation warnings, updating pinned dependencies, rehearsing deployment and rollback, and validating critical authentication, session, admin, and database workflows in staging.