Up to date

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

Politique de publication(release) de Godot

La politique de publication de Godot est en constante évolution. Ce qui est décrit ci-dessous est destiné à donner une idée générale de ce à quoi il faut s'attendre, mais ce qui se passera réellement dépend des choix des principaux contributeurs, et des besoins de la communauté à un moment donné.

Gestion des versions de Godot

Godot suit librement le Semantic Versioning avec un système de versionnement major.minor.patch, mais avec une interprétation de chaque terme adaptée à la complexité d'un moteur de jeu :

• La version major est incrémentée lorsque des ruptures de compatibilité majeures se produisent et impliquent un travail de portage important pour faire passer les projets d'une version majeure à une autre.

  Par exemple, le portage de projets de Godot 3.x à Godot 4.x nécessitent l'exécution du projet par un outil de conversion, puis l'exécution manuelle d'un certain nombre d'ajustements supplémentaires, que l'outil ne pouvait pas faire automatiquement.

• La version minor est incrémentée pour les versions de fonctionnalités qui ne cassent pas la compatibilité de manière majeure. Des ruptures de compatibilité mineures dans des domaines très spécifiques peuvent se produire dans les versions mineures, mais la grande majorité des projets ne devraient pas être affectés ou nécessiter un travail de portage important.

  En effet, Godot, en tant que moteur de jeu, couvre de nombreux domaines tels que le rendu, la physique et les scripts. La correction de bugs ou l'implémentation de nouvelles fonctionnalités dans un domaine peut parfois nécessiter de modifier le comportement d'une fonctionnalité ou de modifier l'interface d'une classe, même si le reste de l'API du moteur reste rétrocompatible.

Astuce

La mise à niveau vers une nouvelle version mineure est recommandée pour tous les utilisateurs, mais certains tests sont nécessaires pour garantir que votre projet se comporte toujours comme prévu.

• La version patch est incrémentée pour les versions de maintenance qui se concentrent sur la correction des bogues et des problèmes de sécurité, l'implémentation de nouvelles exigences pour le support de la plateforme, et l'amélioration de l'utilisabilité. Les versions patch sont rétrocompatibles.

  Les versions correctives (patch) peuvent inclure de nouvelles fonctionnalités mineures qui n'ont pas d'impact sur l'API existante, et ne risquent donc pas d'avoir un impact sur les projets existants.

Astuce

La mise à jour vers les nouvelles versions de patch est donc considérée comme sûre et fortement recommandée à tous les utilisateurs d'une branche stable donnée.

Nous appelons les combinaisons major.minor des branches stables. Chaque branche stable commence par une version major.minor (sans le 0 pour patch) et est développée ultérieurement pour les versions de maintenance dans une branche Git du même nom (par exemple, les mises à jour de correctifs pour la branche stable 4.0 sont développées dans la branche Git 4.0).

Calendrier de support de version

Les branches stables sont prises en charge au minimum jusqu'à ce que la branche stable suivante soit publiée et ait reçu sa première mise à jour. En pratique, nous supportons les branches stables sur une base du meilleur effort aussi longtemps qu'elles ont des utilisateurs actifs qui ont besoin de mises à jour de maintenance.

Whenever a new major version is released, we make the previous stable branch a long-term supported release, and do our best to provide fixes for issues encountered by users of that branch who cannot port complex projects to the new major version. This was the case for the 2.1 branch, and is the case for the 3.x branch.

Pour une version mineure, seul le dernier patch de version recevra des mises à jours. Si vous rencontrez un problème en utilisant une version plus ancienne, merci de mettre à jour vers la dernière version patchée de la version et tester à nouveau avant de reporter ce problème sur GitHub.

Version	Date de publication	Niveau de support
Godot 4.4 (master)	Q1 2025 (estimate)	Développement. Reçoit de nouvelles fonctionnalités, des améliorations de convivialité et de performances, ainsi que des corrections de bogues, pendant le développement.
Godot 4.3	August 2024	Reçoit des correctifs pour les bogues et les problèmes de sécurité, ainsi que des correctifs qui permettent la prise en charge de la plateforme.
Godot 4.2	Novembre 2023	Reçoit des correctifs pour les bogues et les problèmes de sécurité, ainsi que des correctifs qui permettent la prise en charge de la plateforme.
Godot 4.1	Juillet 2023	Reçoit des correctifs pour les bogues et les problèmes de sécurité, ainsi que des correctifs qui permettent la prise en charge de la plateforme.
Godot 4.0	Mars 2023	N’est plus supporté (dernière version : 4.0.4).
Godot 3.7 (3.x)	No ETA for now	Béta. Reçoit de nouvelles fonctionnalités, des améliorations de convivialité et de performances, ainsi que des corrections de bugs, pendant le développement.
Godot 3.6	September 2024	Reçoit des correctifs pour les bogues et les problèmes de sécurité, ainsi que des correctifs qui permettent la prise en charge de la plateforme.
Godot 3.5	Août 2022	Reçoit des correctifs pour les bogues et les problèmes de sécurité, ainsi que des correctifs qui permettent la prise en charge de la plateforme.
Godot 3.4	Novembre 2021	N’est plus supporté (dernière version : 3.4.5).
Godot 3.3	Avril 2021	N’est plus supporté (dernière version : 3.3.4).
Godot 3.2	Janvier 2020	N’est plus supporté (dernière version : 3.2.3).
Godot 3.1	Mars 2019	N’est plus supporté (dernière version : 3.1.2).
Godot 3.0	Janvier 2018	N’est plus supporté (dernière version : 3.0.6).
Godot 2.1	Juillet 2016	N’est plus supporté (dernière version : 2.1.6).
Godot 2.0	Février 2016	N’est plus supporté (dernière version : 2.0.4.1).
Godot 1.1	Mai 2015	N’est plus supporté.
Godot 1.0	Décembre 2014	N’est plus supporté.

Légende : Support complet - Support partiel - Pas de support (end of life) - Version de développement

Les versions de Godot en pré-publication ne sont pas destinées à être utilisées en production et sont fournies pour un usage de testeur.

Voir aussi

Voir Mise à niveau de Godot 3 à Godot 4 pour obtenir des instructions sur la migration d'un projet de Godot 3.x vers 4.x.

Quelle version dois-je utiliser pour un nouveau projet ?

Nous recommandons d'utiliser Godot 4.x pour les nouveaux projets, car la série Godot 4.x sera prise en charge bien après que la version 3.x aura cessé de recevoir des mises à jour dans le futur. Un inconvénient est qu'une grande partie de la documentation tierce n'a pas encore été mise à jour pour Godot 4.x. Si vous devez suivre un tutoriel conçu pour Godot 3.x, nous vous recommandons de garder Mise à niveau de Godot 3 à Godot 4 ouvert dans un onglet séparé pour vérifier quelles méthodes ont été renommées (si vous obtenez une erreur de script en essayant d'utiliser un nœud ou une méthode spécifique qui a été renommé dans Godot 4.x).

Si votre projet nécessite une fonctionnalité manquante dans la version 4.x (comme GLES2/WebGL 1.0), vous devez plutôt utiliser Godot 3.x pour un nouveau projet.

Dois-je mettre à niveau mon projet pour utiliser les nouvelles versions du moteur ?

Note

La mise à niveau d'un logiciel pendant que vous travaillez sur un projet est forcément risquée. Réfléchissez donc à la pertinence de cette idée pour votre projet avant de tenter une mise à niveau. Faites également des sauvegardes de votre projet ou utilisez un outil de contrôle de version pour éviter de perdre des données en cas d'échec de la mise à niveau.

Cela dit, nous faisons de notre mieux pour que les versions mineures et surtout les correctifs restent compatibles avec les projets existants.

La recommandation générale est de mettre à niveau votre projet pour suivre les nouvelles versions de correctifs, comme la mise à niveau de la version 4.0.2 vers la version 4.0.3. Cela vous garantit d'obtenir des correctifs de bogues, des mises à jour de sécurité et des mises à jour de prise en charge de la plateforme (ce qui est particulièrement important pour les plateformes mobiles). Vous bénéficiez également d'une assistance continue, car seule la dernière version de correctif bénéficie d'une assistance sur les plateformes communautaires officielles.

Pour les versions mineures, vous devez déterminer si c'est une bonne idée de procéder à une mise à niveau au cas par cas. Nous avons fait beaucoup d'efforts pour rendre le processus de mise à niveau aussi transparent que possible, mais certaines modifications importantes peuvent être présentes dans les versions mineures, ainsi qu'un risque plus élevé de régressions. Certains correctifs inclus dans les versions mineures peuvent également modifier le comportement attendu d'une classe, comme cela est nécessaire pour corriger certains bogues. C'est particulièrement le cas pour les classes marquées comme expérimentale dans la documentation.

Les versions majeures apportent de nombreuses nouvelles fonctionnalités, mais elles suppriment également des fonctionnalités existantes et peuvent augmenter les exigences matérielles. Leur mise à niveau nécessite également beaucoup plus de travail que les versions mineures. Par conséquent, nous vous recommandons de vous en tenir à la version majeure avec laquelle vous avez démarré votre projet si vous êtes satisfait de la façon dont votre projet fonctionne actuellement. Par exemple, si votre projet a démarré avec la version 3.5, nous vous recommandons de passer à la version 3.5.2 et éventuellement à la version 3.6 à l'avenir, mais pas à la version 4.0+, à moins que votre projet n'ait vraiment besoin des nouvelles fonctionnalités fournies avec la version 4.0+.

Quand sortira le prochain version ?

Bien que les contributeurs de Godot ne soient pas soumis à des contraintes de temps, nous nous efforçons de sortir une nouvelle version mineure relativement fréquemment.

En particulier, après le très long cycle de publication de la version 4.0, nous évoluons vers un flux de travail de développement plus rapide, la version 4.1 étant publiée 4 mois après la version 4.0 et la version 4.2 4 mois après la version 4.1

Des versions mineures fréquentes nous permettront de proposer de nouvelles fonctionnalités plus rapidement (éventuellement à titre expérimental), de recueillir rapidement les retours des utilisateurs et d'itérer pour améliorer ces fonctionnalités et leur facilité d'utilisation. De même, l'expérience utilisateur générale sera améliorée de manière plus constante avec un chemin plus rapide vers les utilisateurs finaux.

Les versions de maintenance (patchs correctifs) seront publiées si besoins avec des cycles de développement très courts, afin de fournir aux utilisateurs de la branche stable actuelle les dernières corrections de bogues pour leurs besoins de production.

There is currently no planned release date for the next 3.x minor version, 3.7. The current stable release, 3.6, may be the last stable branch of Godot 3.x. Godot 3.x is supported on a best-effort basis, as long as contributors continue to maintain it.

Quels sont les critères de compatibilité entre les versions de moteurs ?

Note

Cette partie est destinée à être utilisée par les contributeurs pour déterminer quels changements sont sûrs pour une version donnée. La liste n'est pas exhaustive ; elle ne fait que décrire les situations les plus courantes rencontrées lors du développement de Godot.

Les modifications suivantes sont acceptables dans les versions de correctifs :

• Corriger un bug d'une manière qui n'a pas d'impact négatif majeur sur la plupart des projets, comme un bug visuel ou physique. Le moteur physique de Godot n'est pas déterministe, donc les corrections de bugs physiques ne sont pas considérées comme une rupture de compatibilité. Si la correction d'un bug a un impact négatif qui pourrait avoir un impact sur de nombreux projets, elle doit être rendue facultative (par exemple en utilisant un paramètre de projet ou une méthode distincte).

• Ajout d'un nouveau paramètre optionnel à une méthode.

• Ajustement d'utilisabilité pour un éditeur à petite échelle.

Notez que nous avons tendance à être plus conservateurs avec les corrections que nous autorisons dans chaque nouvelle version de correctif. Par exemple, la version 4.0.1 pourrait recevoir des correctifs plus efficaces que la version 4.0.4.

Les modifications suivantes sont acceptables dans les versions mineures, mais pas dans les versions de correctifs :

• Nouvelles fonctionnalités importantes.

• Renommer un paramètre de méthode. En C#, les paramètres de méthode peuvent être passés par nom (mais pas dans GDScript). Par conséquent, cela peut endommager certains projets qui utilisent C#.

• Dépréciation d'une méthode, d'une variable membre ou d'une classe. Cela se fait en ajoutant un indicateur d'obsolescence à sa référence de classe, qui apparaîtra dans l'éditeur. Lorsqu'une méthode est marquée comme obsolète, elle est censée être supprimée dans la prochaine version majeure.

• Changements qui affectent les visuels du thème par défaut du projet.

• Les corrections de bogues qui modifient de manière significative le comportement ou le résultat, dans le but de mieux répondre aux attentes des utilisateurs. En comparaison, dans les versions correctives, nous favoriserons le maintien d'un comportement bogué afin de ne pas casser les projets existants qui s'appuient probablement déjà sur le bogue ou qui utilisent une solution de contournement.

• Optimisations des performances qui entraînent des changements visuels.

Les modifications suivantes sont considérées comme des briseurs de compatibilité et ne peuvent être effectuées que dans une nouvelle version majeure :

• Renommage ou suppression d'une méthode, d'une variable membre, ou d'une classe.

• Modifier l'arbre d'héritage d'un nœud en le faisant hériter d'une classe différente.

• Modification de la valeur par défaut d'un paramètre de projet d'une manière qui affecte les projets existants. Pour affecter uniquement les nouveaux projets, le chef de projet doit plutôt écrire un project.godot modifié.

Godot 5.0 n'ayant pas encore fait l'objet d'une branche, nous décourageons actuellement les changements de ce type qui brisent la compatibilité.

Note

Lors de la modification de la signature d'une méthode de quelque manière que ce soit (y compris l'ajout d'un paramètre facultatif), une méthode de compatibilité GDExtension doit être créée. Cela garantit que les GDExtensions existantes continuent de fonctionner entre les correctifs et les versions mineures, de sorte que les utilisateurs n'ont pas à les recompiler. Voir Handling compatibility breakages pour plus d'informations.