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 и SpongeVanilla

Ветвь Bleeding

Ядром наших репозиториев является ветка bleeding. Почти все изменения, включая новые функции и исправления ошибок будут добавлены к ней. Версия ветки всегда будет следующей крупной версией релиза с добавлением -SNAPSHOT (например, 8.0.0-SNAPSHOT), чтобы обозначить, что это не окончательная сборка, и в неё могут быть внесены изменения.

Основной причиной наличия ветви bleeding является наличие полигона для внесения изменений. Даже опытные члены команды Sponge могут случайно вызвать сбои в работе или пропустить ошибку. Секция bleeding будет протестирована людьми из сообщества, которые хотят получить самую последнюю версию, а это значит, что мы можем гораздо быстрее исправить возникающие ошибки.

Стабильные ветви

Стабильные ветви представляют собой гораздо более стабильную платформу, на которой могут быть реализованы плагины и серверные реализации. Не будет прерываний API, только неразрушающие дополнения. Существует ветвь, названная в честь каждой крупной версии API, которая содержит новейшие API/реализацию для этой версии, включая любые незначительные выпуски или выпуски исправлений.

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.

Изменения, которые были в bleeding на некоторое время, которые не содержат известных ошибок, и которые могут быть применены к предыдущему главному выпуску, будут отправлены в соответствующую ветку stable для будущей версии. Изменения будут сгруппированы в новую второстепенную версию, если только не требуется немедленное исправление, в этом случае вместо этого будет создана версия с исправлением ошибок. Когда будет выпущена версия, в репозитории API будет создан тег, указывающий на коммит релиза.

Ветви функциональностей (Feature Branches)

Новые возможности или изменения должны быть созданы в ветке feature/foo или fix/bar. Это должно быть основано на самой последнем коммите bleeding. Единственное исключение в том случае, если изменения несовместимы с нарушающими изменениями bleeding, в этом случае вы должны основываться на соответствующем stable-x. В своем pull-request запросе вам необходимо указать, почему ваше изменение не может быть включено в bleeding — например, исправление ошибки в функции, которая была удалена Mojang в более поздней версии.

Если внесенные изменения не нарушают предыдущий релиз, команда Sponge также может включить некоторые изменения (cherry-pick) в одну или несколько stable ветвей, предполагая, что после слияния изменений в bleeding проблем не возникнет.

SpongeDocs

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.

Основная ветвь

Основной веткой для SpongeDocs является stable. Каждый новый коммит в stable вызывает пересборку сайта документации <https://docs.spongepowered.org/>`_. Коммиты в stable чаще всего делаются чтобы описать самый актуальный выпуск SpongeAPI или исправить частые ошибки в документации.

Ветви функциональностей (Feature Branches)

Всякий раз, когда описывается новая функция, старые тексты обновляются или изменяются или документы реструктурируются, это делается в ветке feature/foo или fix/bar. Затем эти ветви будут пересмотрены и, если они будут признаны завершенными, могут быть объединены.

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

Ветвь релиза

SpongeDocs использует ветви release/x.y.z для публикации документации для более старых версий API, таких как API 3.1.0. Более старые выпуски API доступны в соответствующих ветвях. Всякий раз, когда выпускается новая версия API, команда документации создают новую ветвь release/x.y.z и затем перемещает master на новую версию API. коммит в ветвь release также вызывает перестройку более старой версии документации, как и в основной ветке.