Attention! Merge de Vulkan, branche master instable!
Dans la plupart des workflows de développement basés sur Git, la branche master
par défaut est celle où se fait
la majeure partie du développement. Il peut s’agir de branches de fonctionnalités bien définies (ou dans notre cas, de
Pull Requests) qui sont fusionnées dans la branche master une fois prêtes, ou de travaux de développement qui se déroulent
directement sur cette branche. Quel que soit le workflow, la branche master sera rarement destinée à être utilisée en
production, et les utilisateurs sont encouragés à l’utiliser seulement s’ils veulent aider aux tests quotidiens,
et non s’ils veulent s’en servir pour travailler :)
Comme nous faisons nos versions directement à partir de la branche master
après une période de stabilisation (gel des
fonctionnalités, gel des versions, puis bifurcation vers la version 3.2 par exemple lors de la sortie), beaucoup de nos
utilisateurs sont habitués à utiliser la branche master
ou un build de nuit pour un usage quotidien.
Cela change aujourd’hui, car nous fusionnons notre port Vulkan en cours de développement (jusqu’à présent dans la branche Vulkan) dans la branche master.
Pourquoi fusionner maintenant si la branche est encore en développement ?
Le port de Vulkan n’est pas encore prêt, mais nous devons le fusionner dans la branche principale car de nombreux développements futurs prévus pour Godot 4.0 en dépendent.
Nous prévoyons de retravailler beaucoup d’éléments du noyau de Godot pour permettre de résoudre des problèmes de conception
de longue date et d’améliorer les performances (y compris d’améliorer les performances du GDScript). De plus, notre portage
tant attendu vers le C++ 14 se fera également maintenant que la branche vulkan
est fusionnée dans le master
, et de nombreux
autres gros changements au niveau de la codebase l’attendaient : changements de style de code, division Display/OS, renommage
des noeuds 3D pour unifier nos conventions, etc.
L’ampleur des changements prévus signifie qu’il serait impossible de faire ces changements dans la branche master
tout en
gardant la branche vulkan
séparée, tout comme il ne serait pas possible de faire tous ces changements dans la branche vulkan
elle-même avant de la fusionner dans le master
: tout rebase ou merge deviendrait extrêmement difficile en raison de la
quantité de lignes de code qui changeraient.
Jusqu’à présent, nous avons été très prudents en ce qui concerne les changements que nous autorisons dans la branche vulkan
,
ainsi que les nouvelles PR que nous fusionnons dans master
, afin de garantir que la branche vulkan
puisse toujours être
rebasée sur master
pour une fusion ultérieure. Je l’ai rebasée périodiquement au cours des huit derniers mois, et même si
nous avons été très conservateurs quant à l’ampleur des changements, un rebase complet pourrait facilement me prendre une
journée entière de travail au cours des mois suivants.
Nous avons donc besoin que tout ce qui se trouve dans la branche principale cesse de nous limiter.
Quels changements ?
La branche vulkan
comprend le support préliminaire de l’API graphique Vulkan, que Juan a couvert dans de nombreux devblogs
(voir par exemple le dernier rapport d’avancement).
NdT : Certains de ces devblogs ont été traduits sur notre site.
Dans son état actuel, le port Vulkan ne fonctionne que sur Linux, macOS et Windows. La prise en charge des autres plateformes sera rétablie dans les mois à venir, avant la sortie de la version 4.0 alpha.
Les backends GLES2 et GLES3 de Godot 3.2 ont été désactivés car ils ne correspondent pas à la nouvelle conception de l’API
RenderingDevice
. Le GLES3 sera finalement complètement supprimé, et le backend GLES2 devra être porté sur la nouvelle API.
Cela sera également fait dans les mois à venir.
En attendant, cela signifie que la branche master
utilisera Vulkan et ne pourra créer de build que sur ordinateur pendant
un certain temps. Merci de nous faire confiance pendant cette période de transition, et soyez assurés que le retour du support
mobile et web est une priorité. (Notez que les ports de plateforme actuels sont bien sûr toujours inclus dans le dernier
code, mais sans un backend de rendu correctement configuré, ils ne servent à rien).
Implications pour les utilisateurs
Si vous êtes un utilisateur “normal” de Godot, rien ne change pour vous. Nous vous recommandons vivement d’utiliser la dernière version stable, qui est Godot 3.2. Nous sommes tous excités par Godot 4.0, mais au stade actuel, il est beaucoup plus sain d’attendre que les développeurs fassent leur magie. Une fois que nous aurons une version alpha qu’il vaut la peine de tester à grande échelle, nous ne manquerons pas de vous le faire savoir :)
Si vous avez besoin de corrections personnalisées pour votre jeu, n’hésitez pas à suivre la branche stable 3.2, qui sera utilisée pour toutes les prochaines versions de maintenance 3.2.x.
Implications pour les contributeurs
Même si elle est moins stable et ne supporte pas toutes les plateformes, la branche master
reste notre principale branche
de développement, et toute Pull Request devrait être fusionnée en priorité dans cette branche. Les changements pertinents
fusionnés dans la branche master
peuvent éventuellement être cherry-picked dans la branche 3.2 pour les versions de
maintenance (en particulier les corrections de bugs).
Comme les branches master
et 3.2
divergeront rapidement, les modifications sélectionnées peuvent s’avérer non triviales,
et il peut donc s’avérer nécessaire pour les PR concernées par la branche 3.2
de voir également une version personnalisée
pour la branche 3.2
. Cependant, nous vous demandons de vous concentrer d’abord sur la branche master
et de discuter
avec nous si un PR en particulier y serait bienvenu. Nous ne voulons pas fusionner de nouvelles fonctionnalités ou des
changements expérimentaux dans la branche 3.2 qui pourraient compromettre sa stabilité.
Qu’en est-il des Pull Requests en attente ?
En raison du gel des fonctionnalités pour la récente version 3.2, nous avons littéralement des centaines de Pull Requests qui sont en attente de révision/fusion sur le dépôt Godot.
Beaucoup d’entre elles sont pertinentes et mériteraient d’être fusionnées, mais la fusion de la branche vulkan
et le travail
de refactoring à venir introduiront des conflits de fusion complexes pour la grande majorité d’entre elles.
Dans l’idéal, nous voudrions résorber ce retard avant de procéder à des changements aussi massifs, mais nous savons par expérience que nous n’avons pas la capacité de le faire. C’est un beau problème, mais la popularité de Godot et le nombre de PR que nous recevons chaque jour sont extrêmement longs à traiter et il nous faudrait plusieurs mois pour tout gérer (tout en nous efforçant de rattraper les dernières PR).
De plus, beaucoup de ces PR sont antérieurs ou n’ont pas suivi notre nouveau processus de proposition, qui vise à garantir que tous les changements que nous fusionnons sont des ajouts vraiments utiles au moteur et sont soutenus par la communauté. L’examen des PR qui n’ont pas été pré-approuvés au stade de l’idée/conception peut être très difficile, car nous ne savons pas toujours nous-mêmes si une proposition de code est une bonne idée : nous pouvons examiner le code, mais l’examen des cas d’utilisation est une tâche difficile pour laquelle nous avons besoin de l’aide de membres expérimentés de la communauté.
Nous en avons discuté lors du Godot Sprint avec les principaux contributeurs fin janvier, et nous avons décidé que l’approche suivante était la plus pratique. Nous allons fermer toutes les PR en attente, en demandant à leurs auteurs de :
- vérifier si la proposition/le correctif est toujours souhaité/nécessaire dans la branche
master
actuelle ; - pour les propositions de fonctionnalités, assurez-vous qu’elles ont été approuvées via le dépôt godot proposals ;
- le cas échéant, rebasez (ou réimplantez) le patch sur la branche principale actuelle et ouvrez une nouvelle PR (en vous référencant l’ancienne).
Bien que la clôture des RP puisse sembler un peu abrupte, nous demandons à tous les contributeurs de comprendre que cela est fait pour nous aider à faire face à la quantité de propositions tout en devant remanier une grande partie de la codebase du moteur. Cette clôture ne signifie pas que nous rejetons les PR, ni que nous ne les considérons pas comme des contributions valables. Mais en demandant aux auteurs de réévaluer leurs propres propositions et de les rendre compatibles avec Godot 4.0, nous gagnerons un temps de développement précieux et nous nous donnerons un peu d’air dans la quantité de PR énorme actuelle.
Les PR fermées porteront l’étiquette “récupérable” (salvageable
), que nous utilisons pour désigner les PR dont le code
pourrait être récupéré pour en faire une nouvelle PR mise à jour (et éventuellement améliorée), soit par l’auteur original,
soit par un nouveau contributeur. Nous ne perdrons donc pas de code au cours du processus, puisque tout sera toujours
accessible depuis les PR fermées et facilement identifiable grâce à l’étiquette récupérable (salvageable
).
C’est certainement une période délicate pour les développeurs principaux et les contributeurs, et nous demandons à tous de faire preuve de compréhension. Pour ma part, je ressens une obligation morale envers tous les contributeurs de revoir leur travail et de le faire fusionner s’il est bon, et cette proposition de nettoyage n’est donc pas une décision facile à prendre pour moi, mais je crois que c’est le moyen le plus efficace que nous ayons pour éviter de nous retrouver coincés dans un backlog de PR sans fin (comme nous l’étions dans une certaine mesure après la sortie de la version 3.1, même si le backlog était alors d’à peine 250 PR…).
Note : Nous attendrons quelques semaines avant de fermer tous les PR plus anciens comme indiqué plus haut, car de nombreux
changements de base de code sont prévus dans les jours à venir. Nous ne voulons pas encourager tous les contributeurs à refaire
sans cesse leur travail au milieu de ces changements, il sera donc préférable d’envoyer ce signal une fois que la branche
master
sera prête à accueillir ces contributions rafraîchies.