$ the-wire · showcase
Django prepares for calendar versioning with new version tuple support
By RepoJournal · Filed · About Django
Django's core now supports calendar versioning and exposes version components as a named tuple, preparing the framework for its 2028 release naming scheme.
Django's version handling now accommodates the DEP 20 calendar versioning scheme, where feature releases from 2028 will be named YYYY[.N] instead of the current scheme [1]. The version parser now reads components as (year, patch, status, iteration) for calendar versions, while earlier versions keep their five-part structure, and django.VERSION is now a VersionTuple providing `.feature`, `.patch`, `.status`, and `.iter...` attributes [2]. Code that introspects django.VERSION as a plain tuple will continue to work, but code relying on the old positional layout for future versions should be updated to use the new attributes.
A new public helper, `qualname(value)`, lands in `django.utils.module_loading`, returning the fully qualified dotted module path for functions, classes, or types such as `django.db.models.Model` [3]. Migration serializers (`FunctionTypeSerializer`, `TypeSerializer`) now use this shared helper instead of duplicating ad-hoc path extraction logic, which reduces drift between serializers. The pull request notes this implements a public helper function `qualname(value)` in `django.utils.module_loading` to return the fully qualified dotted module path for a function, class, or type [3].
Trunc and Extract database expressions used in migrations with `USE_TZ=True` and no timezone are now deprecated: Django 2029 will store the current timezone in the migration for these operations [4]. Separately, `django.utils.deprecation` no longer imports `django.middleware` at module level, removing a hard dependency on asgiref that broke contexts like PEP 517 build backends resolving `django.__version__` before runtime dependencies are installed [5]. The middleware import is now deferred to the deprecated `__getattr__` path.
On the governance side, the DEPs repository updated language around the annual release cadence introduced by DEP 20, switching Steering Council elections to odd-numbered years starting in 2027, which coincides with version 6.2 [6]. The same repository removed SC voting language from its document, now stating the Steering Council "agrees or decides to take some action," matching its decision-making process [7]. These changes prepare governance documentation for the calendar versioning transition.
Django's Docker test box bumps minimum PostgreSQL to 16 and PostGIS to 3.4, because the public image `postgis/postgis:15-3.2-alpine` is no longer available [8]. The djangoproject.com site added Plausible analytics tracking [9] and a test that runs `collectstatic` with `ManifestStaticFilesStorage` to catch nonexistent file references before deploy [10].
Action items
- → Review any code that reads django.VERSION positionally or compares against old version numbering; prepare for calendar versioning attributes in Django 2028. django/django [plan]
- → Check migrations using Trunc or Extract with USE_TZ=True and no timezone; expect deprecation warnings, with timezone storage coming in Django 2029. django/django [monitor]
- → If you run django-docker-box locally, update to PostgreSQL 16 and PostGIS 3.4 minimums. django/django-docker-box [plan]
References
- [1] Fixed #37271 -- Added calendar version support to django.utils.version. ↗ django/django
- [2] Fixed #37271 -- Added calendar version support to django.utils.version. ↗ django/django
- [3] Fixed #36523 -- Added django.utils.module_loading.qualname helper. ↗ django/django
- [4] Fixed #37013 -- Deprecated Trunc/Extract in migrations with USE_TZ=True and no tzinfo. ↗ django/django
- [5] Refs #37178 -- Deferred django.middleware import in django.utils.deprecation. ↗ django/django
- [6] Updated language for annual release cadence due to DEP 20. (#120) ↗ django/deps
- [7] Removed SC voting language from the document. ↗ django/deps
- [8] Bumped minimum PostgreSQL to 16 and PostGIS to 3.4. ↗ django/django-docker-box
- [9] Added Plausible analytics tracking. ↗ django/djangoproject.com
- [10] Add test to detect production staticfiles issues (#2742) ↗ django/djangoproject.com
