Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Godots Release-Regeln

Die Release-Regeln von Godot befinden sich in ständiger Entwicklung. Die nachstehende Beschreibung vermittelt eine allgemeine Vorstellung davon, was zu erwarten ist, aber was tatsächlich geschieht, hängt von den Entscheidungen der wichtigsten Mitwirkenden und den Bedürfnissen der Community zu einem bestimmten Zeitpunkt ab.

Godots Versionierung

Godot lehnt sich mit einem major.minor.patch-Versionsschema lose an die Semantische Versionierung an, wenn auch mit einer an die Komplexität einer Spiele-Engine angepassten Interpretation der einzelnen Begriffe:

  • Die major-Version wird erhöht, wenn größere Kompatibilitätsbrüche auftreten, die erhebliche Portierungsarbeiten erfordern, um Projekte von einer Major-Version in eine andere zu migrieren.

    Die Portierung von Godot-Projekten von Godot 3.x auf Godot 4.x erfordert beispielsweise, dass das Projekt durch ein Konvertierungstool läuft und dann eine Reihe weiterer Anpassungen manuell vorgenommen werden, die das Tool nicht automatisch vornehmen konnte.

  • Die minor-Version wird für Releases mit neuen Features erhöht, wenn die Kompatibilität nicht wesentlich beeinträchtigt wird. Geringfügige Kompatibilitätsbrüche in sehr spezifischen Bereichen können in Minor-Versionen vorkommen, aber die große Mehrheit der Projekte sollte davon nicht betroffen sein oder signifikante Portierungsarbeiten erfordern.

    Das liegt daran, dass Godot als Spiele-Engine viele Bereiche wie Rendering, Physik und Skripting abdeckt. Die Behebung von Fehlern oder die Implementierung neuer Features in einem Bereich kann es manchmal erforderlich machen, das Verhalten eines Features zu ändern oder die Schnittstelle einer Klasse zu modifizieren, so dass dann aber der Rest der Engine-API abwärtskompatibel bleibt.

Tipp

Die Aktualisierung auf eine neue Minor-Version wird allen Benutzern empfohlen, aber es sind einige Tests erforderlich, um sicherzustellen, dass sich Ihr Projekt weiterhin wie erwartet verhält.

  • Die patch-Version wird für Wartungsversionen erhöht, die sich auf die Behebung von Fehlern und Sicherheitsproblemen, die Implementierung neuer Anforderungen für die Plattformunterstützung und die Rückportierung von sicheren Verbesserungen der Benutzerfreundlichkeit konzentrieren. Patch-Versionen sind abwärtskompatibel.

    Patch-Versionen können kleinere neue Features enthalten, die sich nicht auf die bestehende API auswirken und somit keine Auswirkungen auf bestehende Projekte haben.

Tipp

Die Aktualisierung auf neue Patch-Versionen gilt daher als sicher und wird allen Benutzern eines bestimmten stabilen Branchs dringend empfohlen.

Wir bezeichnen die Kombination major.minor als stabile Branches. Jeder stabile Branch beginnt mit einem major.minor-Release (ohne die 0 für patch) und wird für Wartungsversionen in einem Git-Branch gleichen Namens weiterentwickelt (zum Beispiel werden Patch-Updates für den stabilen Branch 4.0 im Git-Branch 4.0 entwickelt).

Zeitplan für den Support von Releases

Stabile Branches werden mindestens so lange unterstützt, bis der nächste stabile Branch veröffentlicht wird und sein erstes Patch-Update erhalten hat. In der Praxis unterstützen wir stabile Branches auf einer Best-Effort-Basis so lange, wie es aktive Benutzer gibt, die Wartungsaktualisierungen benötigen.

Immer wenn eine neue Major-Version veröffentlicht wird, machen wir den vorherigen stabilen Branch zu einer langfristig unterstützten Version (Long-Term-Support, LTS) und tun unser Bestes, um Fehler zu beheben, die bei Benutzern dieses Branches aufgetreten sind, die aber komplexe Projekte nicht auf die neue Major-Version portieren können. Dies war der Fall für den 2.1-Branch und ist es auch für den 3.6-Branch.

In einer bestimmten Minor-Release-Reihe wird nur das neueste Patch-Release supportet. Wenn Sie ein Problem mit einem älteren Patch-Release haben, aktualisieren Sie bitte auf das neueste Patch-Release dieser Reihe und testen Sie es erneut, bevor Sie ein Problem auf GitHub melden.

Version

Release-Datum

Support-Level

Godot 4.3 (master)

April 2024 (estimate)

unstable Development. Erhält neue Features, Verbesserungen der Benutzerfreundlichkeit und Leistung, sowie Fehlerkorrekturen während der Entwicklung.

Godot 4.2

November 2023

supported Behebung von Fehlern und Sicherheitsproblemen, sowie Patches für die Plattformunterstützung.

Godot 4.1

Juli 2023

supported Behebung von Fehlern und Sicherheitsproblemen, sowie Patches für die Plattformunterstützung.

Godot 4.0

März 2023

eol No longer supported (last update: 4.0.4).

Godot 3.6 (3.x, LTS)

Q1 2024 (estimate)

supported Beta. Erhält neue Features, Verbesserungen der Benutzerfreundlichkeit und Leistung, sowie Fehlerkorrekturen während der Entwicklung.

Godot 3.5

August 2022

supported Behebung von Fehlern und Sicherheitsproblemen, sowie Patches für die Plattformunterstützung.

Godot 3.4

November 2021

eol No longer supported (last update: 3.4.5).

Godot 3.3

April 2021

eol No longer supported (last update: 3.3.4).

Godot 3.2

Januar 2020

eol Nicht mehr unterstützt (letztes Update: 3.2.3).

Godot 3.1

März 2019

eol Nicht mehr unterstützt (letztes Update: 3.1.2).

Godot 3.0

Januar 2018

eol Nicht mehr unterstützt (letztes Update: 3.0.6).

Godot 2.1

Juli 2016

eol Nicht mehr unterstützt (letztes Update: 2.1.6).

Godot 2.0

Februar 2016

eol Nicht mehr unterstützt (letztes Update: 2.0.4.1).

Godot 1.1

Mai 2015

eol Nicht mehr unterstützt.

Godot 1.0

Dezember 2014

eol Nicht mehr unterstützt.

Legende: supported Volle Unterstützung - partial Teilweise Unterstützung - eol Keine Unterstützung (End of Life) - unstable Entwicklungsversion

Vorabversionen von Godot sind nicht für den Einsatz in der Produktion gedacht und werden nur zu Testzwecken bereitgestellt.

Siehe auch

Siehe Upgraden von Godot 3 auf Godot 4 für Anweisungen zur Migration eines Projekts von Godot 3.x auf 4.x.

Welche Version sollte ich für ein neues Projekt verwenden?

Wir empfehlen die Verwendung von Godot 4.x für neue Projekte, da die Godot 4.x-Reihe noch unterstützt werden wird, lange nachdem 3.x keine Updates mehr bekommt. Ein Vorbehalt ist, dass viele Dokumentationen von Drittanbietern noch nicht für Godot 4.x aktualisiert wurden. Wenn Sie ein für Godot 3.x entwickeltes Tutorial befolgen wollen, empfehlen wir, Upgraden von Godot 3 auf Godot 4 in einem separaten Tab geöffnet zu halten, um zu prüfen, welche Methoden umbenannt wurden (falls Sie einen Skriptfehler erhalten, während Sie versuchen, einen bestimmten Node oder eine Methode zu verwenden, die in Godot 4.x umbenannt wurde).

Wenn Ihr Projekt ein Feature benötigt, das in 4.x fehlt (z.B. GLES2/WebGL 1.0), sollten Sie stattdessen Godot 3.x für ein neues Projekt verwenden.

Sollte ich mein Projekt aktualisieren, um neue Engine-Versionen zu verwenden?

Bemerkung

Ein Software-Upgrade während der Arbeit an einem Projekt ist mit Risiken verbunden. Überlegen Sie daher vor dem Upgrade, ob es für Ihr Projekt eine gute Idee ist. Erstellen Sie außerdem Sicherungskopien Ihres Projekts oder verwenden Sie eine Versionsverwaltung, um Datenverluste zu vermeiden, falls das Upgrade schiefgeht.

Dennoch tun wir unser Bestes, um Minor- und insbesondere Patch-Releases mit bestehenden Projekten kompatibel zu halten.

Im Allgemeinen wird empfohlen, Ihr Projekt auf neue Patch-Versionen zu aktualisieren, z.B. von 4.0.2 auf 4.0.3. Dadurch wird sichergestellt, dass Sie Fehlerbehebungen, Sicherheitsaktualisierungen und Aktualisierungen der Plattformunterstützung erhalten (was besonders für mobile Plattformen wichtig ist). Außerdem erhalten Sie weiterhin Support, da nur die letzte Patch-Version auf den offiziellen Community-Plattformen unterstützt wird.

Bei Minor-Releases sollten Sie von Fall zu Fall entscheiden, ob ein Upgrade sinnvoll ist. Wir haben uns sehr bemüht, den Upgrade-Prozess so reibungslos wie möglich zu gestalten, aber es kann sein, dass in Minor-Releases einige Breaking Changes enthalten sind, die das Risiko von Regressionensfehlern erhöhen. Einige Korrekturen, die in den Minor-Releases enthalten sind, können auch das erwartete Verhalten einer Klasse ändern, was manchmal unausweichlich ist, um bestimmte Fehler zu beheben. Dies ist insbesondere bei Klassen der Fall, die in der Dokumentation als experimentell gekennzeichnet sind.

Major-Releases bringen viele neue Funktionen mit sich, aber sie entfernen auch bereits vorhandene Funktionen und können die Hardwareanforderungen erhöhen. Außerdem ist der Aufwand für ein Upgrade im Vergleich zu Minor-Releases deutlich höher. Daher empfehlen wir Ihnen, bei dem Major-Release zu bleiben, mit der Sie Ihr Projekt begonnen haben, wenn Sie mit der derzeitigen Funktionsweise Ihres Projekts zufrieden sind. Wenn Ihr Projekt beispielsweise mit 3.5 begonnen wurde, empfehlen wir ein Upgrade auf 3.5.2 und möglicherweise 3.6 in der Zukunft, aber nicht auf 4.0+, es sei denn, Ihr Projekt benötigt wirklich die neuen Features von 4.0+.

Wann erscheint das nächste Godot-Release?

Godot-Mitarbeiter arbeiten zwar nicht unter Termindruck, aber wir bemühen uns, relativ häufig kleinere Versionen zu veröffentlichen.

Nach dem sehr langen Release-Zyklus für 4.0 stellen wir auf einen schnelleren Entwicklungs-Workflow um, wobei die Veröffentlichung von 4.1 für Ende Q2/Anfang Q3 2023 erwartet wird.

Durch häufige Minor-Releases können wir neue Features schneller bereitstellen (möglicherweise als experimentelle Versionen), schnelles Benutzerfeedback erhalten und diese Features und ihre Benutzerfreundlichkeit durch ständige Iterationen verbessern. Auch die allgemeine Benutzerfreundlichkeit wird durch eine schnelleren Auslieferung zu den Endbenutzern stetig verbessert.

Wartungs (Patch)-Releases werden je nach Bedarf mit potentiell sehr kurzen Entwicklungszyklen veröffentlicht, um die Benutzer des aktuellen stabilen Branches mit den neuesten Fehlerkorrekturen für ihre Entwicklungsanforderungen zu versorgen.

Das 3.6-Release ist nach wie vor geplant und sollte der letzte stabile Branch von Godot 3.x sein. Es handelt sich dabei um eine LTS-Version (Long-Term Support), die wir so lange unterstützen wollen, wie die Benutzer sie noch benötigen (aufgrund fehlender Features in Godot 4.x oder weil sie Spiele veröffentlicht haben, die sie weiterhin für die Plattformanforderungen aktualisieren müssen).

Was sind die Kriterien für die Kompatibilität der verschiedenen Engine-Versionen?

Bemerkung

Dieser Abschnitt soll den Mitwirkenden helfen, festzustellen, welche Änderungen für eine bestimmte Version sicher sind. Die Liste erhebt keinen Anspruch auf Vollständigkeit; sie umreißt lediglich die häufigsten Situationen, die während der Entwicklung von Godot auftreten.

Die folgenden Änderungen sind in Patch-Releases zulässig:

  • Behebung eines Fehlers, der keine größeren negativen Auswirkungen auf die meisten Projekte hat, z.B. ein optischer oder Physik-Fehler. Die Godot-Physik-Engine ist nicht deterministisch, so dass die Behebung von Physik-Fehlern nicht als Kompatibilitätsbruch angesehen wird. Wenn die Behebung eines Fehlers eine negative Auswirkung hat, die sich auf viele Projekte auswirken könnte, sollte sie optional gemacht werden (z.B. durch eine Projekteinstellung oder eine separate Methode).

  • Hinzufügen eines neuen optionalen Parameters zu einer Methode.

  • Kleinere Verbesserungen an der Benutzerfreundlichkeit des Editors.

Beachten Sie, dass wir beim Akzeptieren von Korrekturen immer konservativer vorgehen, je weiter die Patch-Releases fortgeschritten sind. Zum Beispiel darf 4.0.1 umfassendere Korrekturen erhalten als 4.0.4.

Die folgenden Änderungen sind in Minor-Releases akzeptabel, aber nicht in Patch-Releases:

  • Bedeutende neue Features.

  • Umbenennen eines Methodenparameters. In C# können Methodenparameter mit Namen übergeben werden (nicht aber in GDScript). Dies kann dazu führen, dass einige Projekte, die C# verwenden, nicht mehr funktionieren.

  • Eine Methode, Membervariable oder Klasse bekommt den Status deprecated (veraltet). Dies geschieht durch das Hinzufügen eines deprecated-Flags zu ihrer Klassenreferenz, die dann im Editor angezeigt wird. Wenn eine Methode als deprecated markiert ist, soll sie in der nächsten Major-Version entfernt werden.

  • Änderungen, die sich auf die visuelle Gestaltung des Default-Projekt-Themes auswirken.

  • Fehlerkorrekturen, die das Verhalten oder die Ausgabe erheblich verändern, mit dem Ziel, die Erwartungen der Benutzer besser zu erfüllen. Im Vergleich dazu können wir uns bei Patch-Releases dazu entscheiden, ein fehlerhaftes Verhalten beizubehalten, um bestehende Projekte nicht zu kritisch zu beeinflussen, die möglicherweisebereits das Fehlerverhalten bewusst verwenden oder einen Workaround implementiert haben.

  • Leistungsoptimierungen, die zu optischen Veränderungen führen.

Die folgenden Änderungen gelten als Kompatibilitätsbruch und können nur in einer neuen Major-Version durchgeführt werden:

  • Umbenennen oder Entfernen einer Methode, Membervariable oder Klasse.

  • Änderung des Vererbungsbaums eines Nodes, indem er danach von einer anderen Klasse erbt.

  • Ändern des Defaultwerts einer Projekteinstellung in einer Weise, die sich auf bestehende Projekte auswirkt. Um nur neue Projekte zu beeinflussen, sollte der Projektmanager stattdessen eine geänderte project.godot schreiben.

Da Godot 5.0 noch nicht abgebrancht wurde, raten wir derzeit davon ab, solche Änderungen vorzunehmen, die Kompatibilitätsbrüche hervorrufen.

Bemerkung

Wenn die Signatur einer Methode in irgendeiner Weise geändert wird (einschließlich des Hinzufügens eines optionalen Parameters), muss eine GDExtension-Kompatibilitätsmethode erstellt werden. Dies stellt sicher, dass bestehende GDExtensions über Patch- und Minor-Releases hinweg weiter funktionieren, so dass die Benutzer sie nicht neu kompilieren müssen. Siehe pull request #76446 für weitere Informationen.