Organização dos branches do repositório

A disposição dos nossos branches foi pensada para auxiliar versionamento semântico permitindo-nos fazer pequenos lançamentos sem que haja a possibilidade de isso partir algo e sejamos obrigados a tornar esse lançamento numa nova versão pesada. Este layout de branches aplica-se aos repositórios SpongeAPI, SpongeCommon, SpongeForge, e SpongeVanilla mas não ao do SpongeDocs.

SpongeAPI, SpongeCommon, SpongeForge & SpongeVanilla

A _Bleeding Branch_

O núcleo dos nossos repositórios é o branch bleeding. Quase todas as alterações são feitas a este ramo, seja novas funcionalidades, alterações ou correções de bugs. A versão bleeding será sempre a versão do próximo grande lançamento (major release) concatenada com -SNAPSHOT (ex. 8.0.0-SNAPSHOT) para mostrar que não é ainda uma versão final e está sujeita a alterações.

The primary reason for having the bleeding branch is to have a testing ground for changes. Even experienced members of the Sponge team can accidentally cause a build to fail or miss a bug. The bleeding branch will be tested by people in the community that want the very latest, and it means that we can fix bugs that arise far more readily.

Branches Estáveis

Stable branches represent a much more stable platform which plugins and server implementations can be built upon. There will be no breakages to API, only non-breaking additions. There is a branch named after each major API release, which contains the latest API/implementation for that release including any minor or patch releases.

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.

Changes that have been in bleeding for a while, which have no known bugs, and that can be applied to a previous major release will be cherry-picked to the relevant stable branch for future release. Changes will be grouped into a new minor version, unless an immediate fix is preferred in which case a bugfix version will be created instead. When a version is released, the API repository will have a tag created pointing to that release’s commit.

Branches de Funcionalidades

New features or changes should be created in a feature/foo or fix/bar branch. This should be based on the most recent commit to bleeding. The only exception to this is if the changes are incompatible with the breaking changes in bleeding, in which case you should base against the relevant stable-x. You should state in your pull request why your change cannot be included in bleeding - such as fixing a bug in a feature that was removed by Mojang in a later release.

If the changes made are not breaking for a previous release, the Sponge team may also cherry-pick the changes to one or more stable branches assuming that no problems arise after the change is merged into bleeding.


The SpongeDocs themselves are unversioned following our philosophy that they will never be finished, but instead in a constant flux of ever increasing usability. However, they target a specific version of the API, generally the most recent release of SpongeAPI.

Branch Central

The core branch for the SpongeDocs is stable. Each new commit to stable triggers a rebuild of the docs website. Commits to stable are generally made to document the most current SpongeAPI release or to fix minor mistakes on the Docs.

Branches de Funcionalidades

Whenever a new feature is described, older texts are updated or reworded or the documents are restructured, it is done in a feature/foo or fix/bar branch. Those branches will then be reviewed and, once they are deemed complete, may be merged.

A feature branch may only be merged into master if the changes / additions made in it are correct regarding the SpongeAPI release currently targeted by the SpongeDocs. Any feature branches that describe features not yet included in a release stay unmerged until the corresponding API version is released and becomes the new targeted version for the SpongeDocs. However, the Docs team might collect additions for a specific version on a single branch.

release branch example

Branches de Lançamento

SpongeDocs uses release/x.y.z branches to publish Docs for older API versions like API 3.1.0. Older API releases are available on their respective branches. Whenever a new API version is released, the Docs Staff will create a new release/x.y.z branch and bump master to the new API version afterwards. A commit to a release branch also triggers a rebuild of the older Docs release, just like on the core branch.