Politica di rilascio di Godot
La politica di rilascio di Godot è in costante evoluzione. Ciò che è descritto di seguito ha lo scopo di dare un'idea generale di cosa aspettarsi, ma quel che accadrà effettivamente dipende dalle scelte dei contributori principali e dalle esigenze della comunità in un determinato momento.
Controllo delle versioni di Godot
Godot segue vagamente il Semantic Versioning con un sistema di versioning major.minor.patch, sebbene con un'interpretazione di ogni termine adattata alla complessità di un motore di gioco:
La versione
majorè incrementata quando si verificano importanti rotture di compatibilità che implicano un significativo lavoro di conversione per spostare i progetti da una versione major all'altra.For example, porting Godot projects from Godot 3.x to Godot 4.x requires running the project through a conversion tool, and then performing a number of further adjustments manually for what the tool could not do automatically.
The
minorversion is incremented for feature releases that do not break compatibility in a major way. Minor compatibility breakage in very specific areas may happen in minor versions, but the vast majority of projects should not be affected or require significant porting work.This is because Godot, as a game engine, covers many areas like rendering, physics, and scripting. Fixing bugs or implementing new features in one area might sometimes require changing a feature's behavior or modifying a class's interface, even if the rest of the engine API remains backwards compatible.
Suggerimento
Upgrading to a new minor version is recommended for all users, but some testing is necessary to ensure that your project still behaves as expected.
La versione
patchviene incrementata per i rilasci di manutenzione che si focalizzano sul correggere bug e problemi di sicurezza, sull'implementare nuovi requisiti per supporto delle piattaforme, e sul backportare miglioramenti di usabilità sicuri. Rilasci patch sono retro compatibili.Le versioni patch possono includere nuove funzionalità minori che non hanno impatto sull'API esistente, e perciò non c'è rischio di impattare progetti esistenti.
Suggerimento
Perciò aggiornare a nuove versioni patch è considerato sicuro e altamente consigliato a tutti gli utenti di un ramo stabile.
We call major.minor combinations stable branches. Each stable branch
starts with a major.minor release (without the 0 for patch) and is
further developed for maintenance releases in a Git branch of the same name
(for example patch updates for the 4.0 stable branch are developed in the
4.0 Git branch).
Tempistiche di supporto della versione
Stable branches are supported at least until the next stable branch is released and has received its first patch update. In practice, we support stable branches on a best effort basis for as long as they have active users who need maintenance updates.
Ogni volta che viene rilasciata una nuova versione maggiore, rendiamo quella precedente una versione con supporto a lungo termine, e ci impegniamo al massimo per correggere i problemi riscontrati da utenti che non possono trasferire progetti complessi alla nuova versione maggiore. Questo è stato il caso del branch 2.1, ed è il caso del branch 3.x.
In una determinata serie di versioni minori, solo l'ultima riceve il supporto. Se si riscontra un problema utilizzando una versione di patch più vecchia, si prega di aggiornare a quella più recente di quella serie e di eseguire nuovamente il test prima di segnalare un problema su GitHub.
Versione |
Data di rilascio |
Livello di supporto |
Godot 4.5 (master) |
Q3 2025 (estimate) |
|
Godot 4.4 |
March 2025 |
|
Godot 4.3 |
Agosto 2024 |
|
Godot 4.2 |
Novembre 2023 |
|
Godot 4.1 |
Luglio 2023 |
|
Godot 4.0 |
Marzo 2023 |
|
Godot 3.7 (3.x) |
Nessuna data prevista per ora |
|
Godot 3.6 |
Settembre 2024 |
|
Godot 3.5 |
Agosto 2022 |
|
Godot 3.4 |
Novembre 2021 |
|
Godot 3.3 |
Aprile 2021 |
|
Godot 3.2 |
Gennaio 2020 |
|
Godot 3.1 |
Marzo 2019 |
|
Godot 3.0 |
Gennaio 2018 |
|
Godot 2.1 |
Luglio 2016 |
|
Godot 2.0 |
Febbraio 2016 |
|
Godot 1.1 |
Maggio 2015 |
|
Godot 1.0 |
Dicembre 2014 |
|
Legenda: 
Pieno supporto - 
Supporto parziale - 
Non supportato (end of life) - 
Versione di sviluppo
Le versioni di Godot pre-release non sono pensate per essere utilizzate in produzione e sono fornite a solo scopo di collaudo.
Vedi anche
Consultare Passare da Godot 3 a Godot 4 per istruzioni sulla migrazione di un progetto da Godot 3.x a 4.x.
Quale versione dovrei usare per un nuovo progetto?
Consigliamo di utilizzare Godot 4.x per i nuovi progetti, poiché la serie Godot 4.x sarà supportata ben oltre la fine degli aggiornamenti della versione 3.x. Un aspetto da tenere presente è che molta documentazione di terze parti non è ancora stata aggiornata per Godot 4.x. Se si deve seguire un tutorial progettato per Godot 3.x, consigliamo di tenere aperto Passare da Godot 3 a Godot 4 in una scheda separata per verificare quali metodi sono stati rinominati (nel caso in cui si verifichi un errore di script tentando di utilizzare un nodo o un metodo specifico che è stato rinominato in Godot 4.x).
Se il proprio progetto richiede una funzionalità mancante nella versione 4.x (ad esempio GLES2/WebGL 1.0), si dovrebbe piuttosto utilizzare Godot 3.x per un nuovo progetto.
Should I upgrade my project to use new engine versions?
Nota
Upgrading software while working on a project is inherently risky, so consider whether it's a good idea for your project before attempting an upgrade. Also, make backups of your project or use version control to prevent losing data in case the upgrade goes wrong.
Detto questo, facciamo del nostro meglio per far sì che le versioni minori e soprattutto le patch siano compatibili con i progetti esistenti.
The general recommendation is to upgrade your project to follow new patch releases, such as upgrading from 4.0.2 to 4.0.3. This ensures you get bug fixes, security updates and platform support updates (which is especially important for mobile platforms). You also get continued support, as only the last patch release receives support on official community platforms.
For minor releases, you should determine whether it's a good idea to upgrade on a case-by-case basis. We've made a lot of effort in making the upgrade process as seamless as possible, but some breaking changes may be present in minor releases, along with a greater risk of regressions. Some fixes included in minor releases may also change a class' expected behavior as required to fix some bugs. This is especially the case in classes marked as experimental in the documentation.
Major releases bring a lot of new functionality, but they also remove previously existing functionality and may raise hardware requirements. They also require much more work to upgrade to compared to minor releases. As a result, we recommend sticking with the major release you've started your project with if you are happy with how your project currently works. For example, if your project was started with 3.5, we recommend upgrading to 3.5.2 and possibly 3.6 in the future, but not to 4.0+, unless your project really needs the new features that come with 4.0+.
Quando uscirà la prossima versione?
Sebbene i contributori di Godot non abbino scadenze da rispettare, cerchiamo di pubblicare versioni minori con una certa frequenza.
In particular, after the very long release cycle for 4.0, we are pivoting to a faster-paced development workflow, 4.1 released 4 months after 4.0, and 4.2 released 4 months after 4.1.
Rilasci minori frequenti ci consentiranno di rilasciare nuove funzionalità più rapidamente (eventualmente in forma sperimentale), di ricevere rapidamente il feedback degli utenti e di iterare per migliorare tali funzionalità e la loro usabilità. Allo stesso modo, l'esperienza utente generale sarà migliorata in modo più costante, con un percorso più rapido agli utenti finali.
Le versioni di manutenzione (patch) saranno rilasciate quando necessario con cicli di sviluppo potenzialmente molto brevi, per fornire agli utenti della versione stabile attuale le ultime correzioni di bug per le loro esigenze di produzione.
Al momento non è prevista una data di rilascio per la prossima versione minore di 3.x, la 3.7. L'attuale versione stabile, la 3.6, potrebbe essere l'ultima versione stabile di Godot 3.x. Godot 3.x è supportato con il massimo impegno possibile, purché i collaboratori continuino a mantenerlo.
Quali sono i criteri di compatibilità tra le versioni del motore?
Nota
Questa sezione è pensata per essere utilizzata dai collaboratori per determinare quali modifiche siano sicure per una determinata versione. L'elenco non è esaustivo; descrive solo le situazioni più comuni riscontrate durante lo sviluppo di Godot.
Le seguenti modifiche sono accettabili nelle versioni patch:
Correggere un bug in un modo che non abbia un impatto negativo significativo sulla maggior parte dei progetti, come un bug visivo o fisico. Il motore di fisica di Godot non è deterministico, quindi le correzioni di bug sulla fisica non sono considerate una violazione della compatibilità. Se la correzione di un bug ha un impatto negativo che potrebbe avere ripercussioni su molti progetti, dovrebbe essere resa facoltativa (ad esempio, attraverso un'impostazione del progetto o un metodo separato).
Aggiungere un nuovo parametro facoltativo a un metodo.
Aggiustamenti di portata limitata all'usabilità dell'editor.
Si noti che tendiamo a essere più prudenti con le correzioni che consentiamo in ogni successiva versione di patch. Ad esempio, la versione 4.0.1 potrebbe ricevere correzioni più notevoli rispetto alla 4.0.4.
Le seguenti modifiche sono accettabili nelle versioni minori, ma non nelle versioni di patch:
Nuove funzionalità importanti.
Rinominare un parametro di un metodo. In C#, i parametri dei metodi si possono passare per nome (ma non in GDScript). Di conseguenza, ciò può causare problemi in alcuni progetti che utilizzano C#.
Deprecare un metodo, una variabile membro o una classe. Ciò si ottiene aggiungendo un flag "deprecated" al riferimento classe, il quale sarà mostrato nell'editor. Quando un metodo è contrassegnato come deprecato, è previsto che sia rimosso nella prossima versione maggiore.
Cambiamenti che influenzano gli aspetti visivi del tema predefinito del progetto.
Le correzioni di bug che modificano significativamente il comportamento o il risultato, con l'obiettivo di soddisfare al meglio le aspettative degli utenti. In confronto, nelle versioni di patch, potremmo preferire mantenere un comportamento buggato in modo da non compromettere i progetti esistenti che probabilmente già dipendono dal bug o utilizzano una soluzione alternativa.
Ottimizzazioni delle prestazioni che risultano in cambiamenti visuali.
I seguenti cambiamenti sono considerati incompatibili e si possono effettuare solo in una nuova versione principale:
Rinominare o rimuovere un metodo, una variabile membro o una classe.
Modificare l'albero di ereditarietà di un nodo facendolo ereditare da una classe diversa.
Modificare il valore predefinito di un'impostazione del progetto in una maniera che influisce sui progetti esistenti. Per influire solo sui nuovi progetti, il gestore dei progetti dovrebbe piuttosto scrivere un file
project.godotmodificato.
Since Godot 5.0 hasn't been branched off yet, we currently discourage making compatibility-breaking changes of this kind.
Nota
Quando si modifica la firma di un metodo in qualsiasi modo (inclusa l'aggiunta di un parametro facoltativo), è necessario creare un metodo di compatibilità GDExtension. Questo garantisce che le GDExtension esistenti continuino a funzionare anche nelle versioni di patch e minori, affinché gli utenti non debbano ricompilarle. Consultare Gestione delle interruzioni di compatibilità per ulteriori informazioni.