Marcus Chen, YuSMP Group
Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Python/Django-Backend-Architektur für US/EU-Produktteams
Geometrische grüne Schlange auf einem bunten Diagramm des jährlichen Release-Zyklus mit Backend-Code-Editor im Dark Mode – Python-Webframework-Versionierung

Die Kurzfassung

Am 10. August 2026 akzeptierte Djangos Steering Council DEP 20 und wechselt ab Januar 2028 zu einem einzigen jährlichen Feature-Release. Versionsnummern tragen künftig das Erscheinungsjahr (Django 2028, Django 2029). Die Bezeichnung „LTS" wird abgeschafft: Jedes Release erhält nun drei Jahre Support – ein Jahr reguläre Bugfixes, dann zwei Jahre Sicherheits- und Datenverlust-Patches. Drei aktuelle Versionen sind stets gleichzeitig unterstützt.

Für Teams, die heute Django-Backends betreiben, ist die unmittelbare Konsequenz einfach: Bis 2028 ändert sich nichts. Django 6.1 und 6.2 LTS behalten ihre bestehenden Supportverpflichtungen vollständig.

Was der Steering Council entschieden hat

Django liefert seit Version 1.0 im Acht-Monats-Rhythmus aus und produziert pro Jahr zwei reguläre Releases und ein LTS-Release. DEP 20 ersetzt dies durch ein einziges Jahresrelease, per Abstimmung des Steering Councils akzeptiert und am 10. August 2026 im offiziellen Django-Weblog veröffentlicht.

Die Kernänderung: Ein Feature-Release pro Kalenderjahr, jedes mit dem gleichen Drei-Jahres-Supportfenster, das bisher LTS-Releases vorbehalten war. „LTS" als separates Label verschwindet, weil die Unterscheidung nicht mehr existiert – jedes Release ist per Definition langfristig unterstützt.

Was mit Django 6.1 und 6.2 LTS passiert

Bestehende Supportverpflichtungen bleiben unverändert:

ReleaseErscheintEnd-of-LifeHinweise
Django 6.1August 2026Dezember 2027Standard-Release, unverändert
Django 6.2 LTSApril 2027April 2030Letztes Release mit dem LTS-Label
Django 2028Januar 2028Dezember 2030Erstes Jahresrelease, 3 Jahre Support, kein LTS-Tag
Django 2029Januar 2029Dezember 2031Stets drei gleichzeitig unterstützte Versionen

Neue Versionsnummern: Django 2028, 2029

Ab 2028 tragen Django-Versionen das Erscheinungsjahr statt semantischer Versionsnummern. Dies beseitigt eine implizite Mehrdeutigkeit: Bei semantischen Versionen fragen Teams oft: „Wie groß ist dieses Upgrade?" Jahresbasierte Nummerierung macht den Rhythmus explizit. Ein Delta von Django 2028 zu Django 2029 entspricht unmissverständlich einem Jahresinkrement.

Es eliminiert auch die praktische Frage, ob eine Version LTS ist oder nicht. Die Antwort lautet stets: ja, drei Jahre.

Was der LTS-Wegfall für die Update-Planung bedeutet

Im alten Modell standen Teams vor einer binären Wahl: Feature-Releases alle acht Monate verfolgen oder sich auf LTS verankern und eine lange Migrationslücke in Kauf nehmen. Teams auf LTS blieben oft bis zum Ablauf auf einer Version, um dann in einem komprimierten Zeitfenster eine mehrjährige Migration durchzuführen.

Im neuen Modell sind stets drei gleichzeitige Versionen unterstützt. Wer Django 2028 betreibt und im Folgejahr nicht auf Django 2029 migriert, erhält Sicherheits-Patches bis Dezember 2030. Es gibt keine Strafe für ein jährliches Überspringen. Upgrade-Entscheidungen können an Features und Team-Kapazität ausgerichtet werden, nicht an einem Support-Fristkalender.

Für Organisationen mit Compliance-Anforderungen – SOC 2, ISO 27001, DSGVO oder HIPAA – beseitigt die vereinfachte Support-Matrix eine häufige Ambiguität bei Sicherheitsprüfungen: Jede Version in der Support-Tabelle trägt dieselbe Klasse von Sicherheitspflege.

Warum die Python-Ausrichtung wichtig ist

Die Begründung von DEP 20 konzentriert sich auf Pythons eigenen Release-Rhythmus. Python liefert jedes Jahr im Oktober eine neue Version aus. Djangos Acht-Monats-Zyklus „passte nicht gut dazu": LTS-Releases akkumulierten eine breite Python-Versionsmatrix, die auch Python-Versionen jenseits ihres eigenen Upstream-EOL enthielt – ein Wartungsaufwand für das Django-Team und nachgelagerte Paketbetreuer.

Im Jahresmodell unterstützt jedes Django-Release die drei neuesten Python-Versionen zum Release-Zeitpunkt und nimmt die neue Python-Version im ersten Support-Jahr auf – ohne dass ein separates LTS-Build die erweiterte Python-Matrix tragen muss.

Was das für DACH-Softwareteams bedeutet

Kurzfristig (vor 2028): keine Änderung. Django 6.1 erscheint im August 2026 und läuft bis Dezember 2027. Django 6.2 LTS erscheint im April 2027 und läuft bis April 2030. Teams auf beiden Versionen setzen ihre bestehenden Supportbedingungen fort. Kein Migrationsdruck.

Langfristig (ab 2028): Der Upgrade-Rhythmus wird einfacher zu planen. Eine Version pro Jahr, drei Jahre Sicherheits-Support, stets drei gleichzeitig unterstützte Versionen. Teams können eine klare Richtlinie definieren – etwa „wir bleiben innerhalb von zwei Versionen des Aktuellen" – ohne zwischen LTS und Nicht-LTS-Builds unterscheiden zu müssen.

Was das für den DACH-Markt bedeutet: Unternehmen in Deutschland, Österreich und der Schweiz profitieren besonders von der vereinfachten Support-Matrix. BSI-Grundschutz und die seit Oktober 2024 in deutsches Recht umgesetzte NIS2-Richtlinie verlangen eine nachvollziehbare Dokumentation des Software-Lebenszyklus. Die neue einheitliche Drei-Jahres-Regel beantwortet die zentrale Prüffrage – „Wird dieses Dependency aktiv gewartet?" – ohne Label-Ambiguität. Auch DSGVO-Audits und Lieferantenprüfungen werden schlanker: Sicherheits-Patches kommen für alle Versionen in der Support-Tabelle mit identischer Verbindlichkeit.

Häufig gestellte Fragen

Wann beginnt Djangos jährlicher Release-Zyklus?

Der neue Jahresrhythmus beginnt mit Django 2028, erwartet im Januar 2028. Bis dahin ändert sich nichts. Django 6.1 und 6.2 LTS behalten ihre bestehenden Support-Zeitpläne.

Was passiert mit Django-LTS-Releases?

Das LTS-Label wird ab Django 2028 eingestellt. Jeder Feature-Release im neuen Zyklus erhält ein identisches Drei-Jahres-Supportfenster. Django 6.2 ist das letzte Release mit dem LTS-Label, da es vor der DEP-20-Änderung liegt.

Müssen Teams Django jetzt häufiger aktualisieren?

Nein – und in der Praxis weniger Druck. Drei gleichzeitige Versionen sind stets unterstützt, sodass das Überspringen eines Jahresreleases keine Konsequenzen hat. Teams können upgraden, wenn Features oder Business-Anforderungen es rechtfertigen.

Welche Python-Versionen unterstützt Django 2028?

Jedes Django-Jahresrelease unterstützt die drei neuesten Python-Versionen zum Release-Zeitpunkt und nimmt die neue Python-Version (erwartet Oktober 2027) im ersten Support-Jahr auf.

Was ist DEP 20?

DEP 20 ist Django Enhancement Proposal 20, die formale Spezifikation für den Wechsel zum Jahresrhythmus. Er wurde vom Steering Council akzeptiert und am 10. August 2026 im offiziellen Django-Weblog veröffentlicht. Der vollständige Vorschlag ist im Repository django/deps auf GitHub verfügbar.

Quellen

Entwickeln oder pflegen Sie ein Python/Django-Backend für ein US- oder EU-Produkt? Sprechen Sie mit unserem Team über Architektur, Upgrade-Planung oder Staff-Augmentation für Ihren Engineering-Sprint.