Welche Pakete blockieren mein Django-Upgrade?

Zwei Angaben, die Maintainer zu ihrem Paket veröffentlichen, entscheiden über ein Upgrade:

• Framework :: Django :: 5.2 Ein Classifier. Er nennt eine Django-Version, die das Paket unterstützt.
• Django>=4.2,<6.1 Die Django-Anforderung. Sie entscheidet, mit welchen Versionen sich das Paket installieren lässt. Eine Obergrenze wie diese schließt 6.1 aus.

Zusammen ergibt das für jede Django-Version einen von drei Zuständen: deklariert, ausgeschlossen oder nicht deklariert. Blockieren kann nur ein Ausschluss. Nicht deklariert heißt, dass niemand etwas gesagt hat. Meist fehlt nur ein Classifier, manchmal pflegt niemand mehr das Paket.

Wie das in der Praxis aussieht, habe ich am 28. September 2026 geprüft: jeweils die neueste Version der 200 meistgeladenen Django-Pakete, gegen Django 5.2, 6.0 und 6.1.

Die Downloads sind die der 30 Tage vor dem 1. September 2026. Geprüft wurde nach den Regeln von django-upgrade-report 0.2.2, die in dessen README stehen. Downloads sind keine Installationen, und die Pakete wurden nach ihrem Namen ausgewählt. Einige Django-Pakete mit ungewöhnlichem Namen fehlen deshalb. Die Rohdaten stehen bei den Quellen.

Django 5.2 LTS: kein Paket schließt es aus

Keines der 200 Pakete schließt 5.2 aus. Die 62 %, die es deklarieren, stehen für 81 % der Downloads. Wer noch auf Django 4.2 ist, wird also nicht von den Paketen aufgehalten. Warten sollte man trotzdem nicht: Bei 30 der 200 lässt sich die neueste Version nicht mehr mit 4.2 installieren, darunter Django REST framework, django-filter und django-debug-toolbar. Jeder Monat auf 4.2 hält mehr Pakete auf alten Versionen fest.

Django 6.1: meist nur Classifier im Rückstand

Django 6.1 ist am 5. August 2026 erschienen. Bisher deklarieren es 29 Pakete, 5 schließen es aus. 53 deklarieren 6.0, aber noch nicht 6.1, darunter pytest-django, django-cors-headers und whitenoise. Von den 48 Paketen mit einem Release seit dem 5. August deklariert die Hälfte 6.1. Das sieht nach Rückstand aus, nicht nach Inkompatibilität.

Echte Blocker gibt es wenige, aber sie sind verbreitet

Diese fünf Pakete schließen 6.1 in ihrer neuesten Version aus. Wer eines davon nutzt, wartet auf ein Release, nimmt einen Fork oder ersetzt es:

• django-celery-beatDjango<6.1, 7,6 Mio. Downloads im Monat
• django-prometheusDjango<6.1, 4,2 Mio. Downloads im Monat
• drf-extensionsDjango<6.0, 2,4 Mio. Downloads im Monat
• django-scim2Django<6.1, 2,2 Mio. Downloads im Monat
• django-postgres-extraDjango<6.0, 0,4 Mio. Downloads im Monat

Das leise Risiko: Pakete, die niemand pflegt

37 der 200 Pakete hatten seit mehr als zwei Jahren kein Release. Alle gehören zu den 75, die 5.2 nicht deklarieren, darunter django-model-utils mit 4,9 Mio. Downloads im Monat, djangorestframework-csv und django-ratelimit. So ein Paket kann weiter funktionieren. Bricht es aber mit der nächsten Version, behebt das niemand. Dann braucht das Upgrade einen Ersatz, und ein Ersatz braucht Zeit.

Ein Paket, das die Zielversion unterstützt, hat einen von zwei Plätzen. Läuft die Version, die das Ziel deklariert, noch auf deinem jetzigen Django, aktualisierst du es vorher und einzeln, und es geht live, bevor sich Django ändert. Hat diese Version dein jetziges Django schon fallen gelassen, muss sie in derselben Änderung kommen wie Django.

Und die neueste Version ist oft die falsche. Die neueste django-debug-toolbar, 8.0, verlangt Django 5.2. Auf 4.2 ist der richtige Schritt 5.1.0, die älteste Version, die 5.2 deklariert. Solche kleinen Schritte halten jede Änderung überschaubar.

So sieht das für ein Beispielprojekt aus, Django 4.2.7 mit 18 Django-Paketen, geplant für 5.2:

Insgesamt: 15 Pakete vor Django aktualisieren, 3 von Hand prüfen, keines blockiert. Zwei der Updates verlangen eine neuere Patch-Version von Django 4.2. Der erste Schritt ist also ein Update innerhalb von 4.2.

Aus dieser Prüfung habe ich ein kostenloses Open-Source-Werkzeug gemacht: django-upgrade-report. Es liest dein Lockfile oder deine Requirements, fragt PyPI, was jedes Django-Paket erklärt, und gibt den Plan aus: blockiert, vorher aktualisieren, zusammen mit Django aktualisieren, von Hand prüfen, bereit. Im Projektverzeichnis genügt ein Befehl:

uvx django-upgrade-report

Es braucht Python 3.10 oder neuer, aber weder Django noch dein Virtualenv. An PyPI gehen nur Paketnamen und Versionen, nie dein Code. Pakete aus Git oder einem privaten Index werden gar nicht nachgeschlagen. In CI läuft es auch, mit Markdown, JSON oder einem HTML-Bericht.

django-upgrade-report auf GitHub