Système de Gestion de Versions et Disposition de Branches du Dépôt

Avec la sortie de la bêta, nous avons déplacé le système de versions de SpongeAPI au semantic versioning (voir http://semver.org/). Ce changement signifie qu’à chaque fois que nous faisons une release, nous devons incrémenterrr la version conformément aux règles de semver.

SemVer

SemVer utilise le schéma X.Y.Z, où X est une version majeure, Y est une mineure et Z est une version patch. Une release qui contient des changements qui ne sont pas rétro-compatibles doit être une version majeure de plus que la release précédente. Si il y a seulement de nouvelles fonctionnalités qui sont rétro-compatibles, alors la nouvelle release sera une version mineure de plus que la release précédente, et si la release contient seulement des bugfixes alors la version patch sera incrémentée.

Cela signifie que par exemple 3.2.0 est entièrement compatible avec 3.0.0 alors que 4.0.0 n’est pas binairement compatible avec 3.0.0. 3.1.0 et 3.1.2 sont parfaitement inteerchangeables sans compter les bugs qui ont été résolus.

La disposition de nos branches (décrites ci-dessous) est conçue pour aider le processus en nous permettant de faire des releases mineures sans changements qui casserait tout, nous forçant à faire une release majeure. Cette disposition de branches s’applique aux dépôts SpongeAPI, SpongeCommon, SpongeForge et SpongeVanilla mais pas à SpongeDocs.

SpongeAPI, SpongeCommon, SpongeForge et SpongeVanilla

La Branche Bleeding

Le coeur de nos dépôts est la brarnche bleeding. Presque toutes les modifications seront ajoutées à bleeding, y compris les nouvelles fonctionnalités, les changements, et les corrections. La version de bleeding` serra toujours la prochaine version majeure de la release suffixé de -SNAPSHOT (par exemple 6.0.0-SNAPSHOT) pour indiquer que ce n’est pas encore une build finale et qu’elle sujette aux 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-5. bledding serra correctement mis à jour à la prochaine release 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érralement la release la plus récente de SpongeAPI.

Branche Core

La branche core pour les SpongeDocs est master. Chaque nouveau commit vers master déclenche un rebuild du site web des docs. Les commits vers master 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 faîtes à 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.