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 "majeure" 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 2.1 à Godot 3.0 a nécessité 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 "mineure" est incrémentée pour les versions de fonctionnalités qui ne rompent 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.
La raison en est qu'en tant que moteur de jeu, Godot couvre de nombreux domaines tels que le rendu, la physique, les scripts, etc., et la correction de bugs ou l'implémentation de nouvelles fonctionnalités dans un domaine donné peut parfois nécessiter de changer le comportement d'une fonctionnalité, ou de modifier l'interface d'une classe donnée, même si le reste de l'API du moteur reste rétrocompatible.
Astuce
La mise à niveau vers une nouvelle version mineure est donc recommandée pour tous les utilisateurs, mais certains tests sont nécessaires pour s'assurer que votre projet se comporte toujours comme prévu dans une nouvelle version mineure.
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 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 majeure.mineure des branches stables. Chaque branche stable commence par une version majeure.mineure (sans le 0 pour patch) et est développée pour les versions de maintenance dans une branche Git du même nom (par exemple les mises à jour de patch pour la branche stable 3.3 sont développées dans la branche Git 3.3).
Note
Comme mentionné dans l'introduction, la politique de publication de Godot évolue, et les versions précédentes de Godot peuvent ne pas avoir suivi les règles ci-dessus à la lettre. En particulier, la branche stable 3.2 a reçu un certain nombre de nouvelles fonctionnalités dans la version 3.2.2 qui auraient justifié un incrément de version "mineur".
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 de meilleur effort aussi longtemps qu'elles ont des utilisateurs actifs qui ont besoin de mises à jour de maintenance.
Chaque fois qu'une nouvelle version majeure est publiée, nous faisons de la branche stable précédente une version supportée sur le long terme, et faisons de notre mieux pour fournir des corrections pour les problèmes rencontrés par les utilisateurs de cette branche qui ne peuvent pas porter des projets complexes vers la nouvelle version majeure. C'était le cas pour la branche 2.1, et ce sera le cas pour la dernière branche stable 3.x au moment de la sortie de Godot 4.0.
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.0 |
~2022 (voir ci-dessous) |
|
Godot 3.5 |
Q1 2022 |
|
Godot 3.4 |
Novembre 2021 |
|
Godot 3.3 |
Avril 2021 |
|
Godot 3.2 |
Janvier 2020 |
|
Godot 3.1 |
Mars 2019 |
|
Godot 3.0 |
Janvier 2018 |
|
Godot 2.1 |
Juillet 2016 |
|
Godot 2.0 |
Février 2016 |
|
Godot 1.1 |
Mai 2015 |
|
Godot 1.0 |
Décembre 2014 |
|
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.
Quand sortira le prochain version ?¶
Bien que les contributeurs de Godot ne soient soumis à aucune date limite, nous avons toujours eu une version majeure ou mineure par an, avec plusieurs mises à jour de maintenance entre chacune.
Depuis la sortie de Godot 3.3, nous visons à accélérer nos cycles de développement pour les versions mineures, vous pouvez donc vous attendre à une nouvelle version mineure tous les 3 à 6 mois.
Les versions de maintenance (correctifs) seront publiées selon les besoins avec des cycles de développement potentiellement très courts, afin de fournir aux utilisateurs de la branche stable actuelle les dernières corrections de bogues pour leurs besoins de production.
En ce qui concerne le prochain Godot 4.0, nous pouvons seulement dire que nous visons une version ** 2022 **, mais une estimation plus précise sera probablement difficile à maintenir. Les versions alpha seront publiées dès que les principales fonctionnalités de Godot 4.0 seront finalisées.