Repository Branch Layout

The layout of our branches is designed to assist semantic versioning by allowing us to make minor releases without a breaking change forcing us to make it a major release. This branch layout applies to SpongeAPI, SpongeCommon, SpongeForge, and SpongeVanilla repositories but not to the SpongeDocs.

SpongeAPI, SpongeCommon, SpongeForge et SpongeVanilla

La Branche Bleeding

The core of our repositories is the bleeding branch. Almost all changes will be added to bleeding, including new features, changes, and bugfixes. The version of bleeding will always be the next major release version appended with -SNAPSHOT (e.g. 7.0.0-SNAPSHOT) to denote that it is not yet a final build and subject to change.

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.

When the time comes to release a major version, a new stable-x branch will be created from bleeding, where x is the new major version - for example, stable-7. bleeding will be appropriately updated to be the next major release as described above.

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.

release branch example

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.