Organisation des branches du dépôt
La disposition de nos branches respecte le versionnage sémantique ce qui nous permet de faire des mises à jour mineures sans changements qui nous forceraient à faire une mise à jour majeure. Cette disposition s’applique aux dépôts SpongeAPI, SpongeCommon, SpongeForge et SpongeVanilla mais pas à SpongeDocs.
SpongeAPI, SpongeCommon, SpongeForge et SpongeVanilla
La Branche Bleeding
Le cœur de nos dépôts est la branche bleeding. Presque toutes les modifications seront ajoutées à bleeding, y compris les nouvelles fonctionnalités, les changements, et les corrections. La version de bleeding sera toujours la prochaine version majeure de la release suffixée par -SNAPSHOT (par exemple 8.0.0-SNAPSHOT) pour indiquer que ce n’est pas encore une version finale et qu’elle sujette à changements.
La raison primaire d’avoir une branche bleeding est d’avoir un terrain d’essai pour les changements. Même les membres expérimentées de l’équipe de Sponge peuvent accidentellement fairre échouer un build ou rater un bug. La branche bleeding sera testée par les gens dans la communauté qui veulent la toute dernière version, et cela signifie que nous pouvons corriger les bugs qui surviennent beaucoup plus facilement.
Branches Stables
Les branches stables représentent une plateforme beaucoup plus stable sur laquelle les plugins et les implémentations de seveurs peuvent être builds. Il n’y aura aucune casse à l’API, seulement des ajouts sans rupture. Il y a une branche nommée après chaque release majeure de l’API, qui contient la dernière API/implémentation pour cette release y compris les releases mineures ou patchs.
Quand vient le temps de sortir une version majeure, une nouvelle branche stable-x sera créée à partir de bleeding, où x est la nouvelle version majeure - par exemple, stable-7. bleeding sera correctement mis à jour à la prochaine mise à jour majeure comme décrit ci-dessus.
Les changements qui ont été dans bleeding pendant longtemps, qui n’ont pas de bug connu, et qui peuvent être appliqués à la précédente release majeure seront sélectionnés pour la branche stable pour les prochaines releases. Les changements seront groupés en une nouvelle version mineure, sauf si un correctif immédiat est préférable, dans quel cas une version de correction sera créée à la place. Lorsqu’une version sort, le dépôt de l’API aura une étiquette créée pointant sur le commit de cette release.
Branches de Fonctionnalités
Les nouvelles fonctionnalités ou changements doivent être créés dans une branche feature/foo ou fix/bar. Elle doit êtrer basée sur le commit le plus récent de bleeding. La seule exception à cela est si les modifications sont incompatibles avec les changements avec rupture dans bleeding, dans quel cas vous devez vous baser contre le stable-x pertinent. Vous devez explique dans votre pull request pourquoi vos changements ne peuvent pas être inclus dans bleeding - comme lors de la correction d’un bug dans une fonctionnalité qui a été supprimée par Mojang dans une version ultérieure.
Si les changements faits ne sont pas cassés pour une version antérieure, l’équipe de Sponge peut également sélectionner les changements d’une ou plusieurs branches stable en supposant qu’aucun problème ne survienne après que les changements ne soient fusionnés dans bleeding.
SpongeDocs
Les SpongeDocs eux-mêmes sont non versionnés en suivant notre philosophie qu’ils ne seront jamais terminés, mais plutôt dans un flux constant avec une utilisation de plus en plus simple. Cependant ils ciblent une version spécifique de l’API, généralement la release la plus récente de SpongeAPI.
Branche Core
La branche core pour les SpongeDocs est stable. Chaque nouveau commit vers stable déclenche un rebuild du site web des docs. Les commits vers stable sont généralement faits pour documenter la version la plus récente de SpongeAPI ou pour corriger des erreurs mineures sur les Docs.
Branches de Fonctionnalités
Lorsqu’une nouvelle fonctionnalité est décrite, les anciens textes sont mis à jour ou reformulés ou les documents sont restructurés, c’est fait dans une branche feature/foo ou fix/bar. Ces branches seront alors examinées et, une fois qu’elles seront jugées complètes, pourront être fusionnées.
Une branche de fonctionnalité peut seulement être fusionnée dans master si les changements/additions faits à l’intérieur de celle-ci sont corrects en ce qui concerne la version de SpongeAPI actuellement visée par les SpongeDocs. Les branches de fonctionnalités qui décrivent des fonctionnalités ne figurant pas encore dans une release restent non fusionnées jusqu’à que la version de l’API correspondante sortent et devienne le nouvelle version ciblée par SpongeDocs. Cependant l’équipe des Docs meut collecter des additions pour une version spécifique sur une seule branche.
Branches de Releases
SpongeDocs utilise les banches release/x.y.z pour publier les Docs pour les anciennes versions de l’API comme 3.1.0. Les anciennes releases de l’API sont disponibles dans leurs branches respectives. Lorsqu’une nouvelle version de l’API sort, l’équipe des Docs va créer une nouvelle branche release/x.y.z et mettront master à la nouvelle version de l’API par la suite. Un commit vers la branche release déclenche également un rebuild des anciennes releases des Docs, juste comme sur la branche core.
